Increase your efficiency with Appian’s Multi-Purpose Forms

Share on facebook
Share on google
Share on twitter
Share on linkedin

Increase your efficiency with Appian’s Multi-Purpose Forms


By
Aaron Emmert

A core aspect of any business process management (BPM) system is to collect information from users through forms that are saved for viewing or further action. The design of these forms ranges in complexity from charts and graphs to simple text fields.

When you’re planning on implementing business processes, your first priority should be to compare other processes you want to create to see if there are enough similarities to use a shared process model. If your processes are too unique, they’ll get their own unique process model. That way multiple business processes can be built out at the same time for increased development productivity. Processes that share a lot of similarities can be merged into one for reusability.

To take it a step further, what if we could put all questionnaire type forms into one process model while staying true to readability, maintainability, scalability, and performance? It’s important to make sure that any added complexity will have a greater return on investment rather than staying with the status quo. Within Appian, a low-code BPM system, this can be accomplished with the Multi-Purpose Form (MPF) design structure in their out-of-the-box components. Before we dive into the example, let’s review some Appian concepts.

Custom Data Types

In Appian, a logical grouping of data is called a Custom Data Type (CDT). An example of how we can use CDT would be if we create a Phone CDT, with the properties of: number, extension, country code, area code, etc. We can then use a single variable to hold all the Phone CDT information, instead of using a variable for each property (number, extension, etc.).

For another example, let’s say we have CDTs that match their respective table in a database.  We’d have a database table called Phone and a matching CDT also called Phone. The table columns will match the CDT properties (number, extension, etc.). When it’s properly linked, we’ll be able to search, create, update, or delete Phone information from Appian.

With the CDT information in mind, let’s take a look at the process model.

Process Model of the Multi-Purpose Form Part 1

One of the common ways a user starts a process is by going to the Actions tab which is essentially a series of links they can click on. By starting processes from other locations, such as a record, you can pass in a series of parameters to populate certain variables. Normally these variables will be IDs so you can search for the matching CDT within the process model. In the example above the respective variables will be populated when the “Load (A,B,C) CDTs” nodes execute.

Since this process model will support different forms, certain variables can be skipped. For example, the diamond “Skip (A,B,C) Load?” nodes. This will help with performance and maintainability by keeping the process footprint small. In other words, only load what you need. For example, a “Patient Outreach” task where the user needs to contact the patient will need the Phone information whereas an “Enter Lab Date” task will not.

Parent Interface of the Multi-Purpose Form

When the form loads – the “Show Form” node in our example – we pass it the populated respective CDTs the user needs to complete the form. In a similar way of skipping unneeded CDTs in our process model, we can also hide unrelated sections. For our “Patient Outreach” example, we’ll display Section A, place the Phone information in Context A-1, collect the response in Question A-1, and hide the other sections.

Process Model of the Multi-Purpose Form Part 2

After the user completes and submits the form, the last thing to do in the process model is to save the information. For our example of “Patient Outreach” we only need to save the response. We don’t need to save the Phone information because the user only needed to view that information and no updates were made to it on the form. Therefore, the respective branch for response executed while the others will be skipped. The process will then terminate and we’ve successfully completed our example!

In conclusion, using this design pattern allows you to show a dynamic form all within one process model. All that’s required is keeping track of reference information such aswhat information to search, which sections to display on the form, and which information to save. You can further optimize the design to show or hide fields within each section for even more customization.

About the author

Aaron Emmert Headshot

As an Appian developer, Aaron strives to meet and exceed the expectations of our clients. He grew up in Superior, Wisconsin, where he’s a fan of the Packers, dairy products, and cider. His hobbies include walking the dog, exercising, reading and playing video games. Read more of Aaron’s blogs here.

About us

Bits In Glass is an award-winning software consulting firm. We combine our deep industry expertise and experience with the best names in technology to provide innovative solutions to your unique business challenges. Our expert consultants excel at solving complex technical problems across industries and verticals, specializing in healthcare, financial services, insurance, and the public sector. Let us help you improve operations, drive better customer experiences, and return more to your bottom line.

Subscribe to Bits In Glass

Get the latest news and updates directly in your inbox.

Check out our video library!

Learn how Appian helped top brands gain success.