Blog: Increase your efficiency with Appian’s Multi-Purpose Forms

Aaron EmmertAppian, Blog

Increase your efficiency with Appian’s Multi-Purpose Forms

By Aaron Emmert, Bits In Glass

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.


Like this content? Subscribe to our blog for all the latest updates!

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 Bits In Glass
Bits In Glass is an award-winning software consulting firm that helps companies transform, outpace the competition, drive rapid growth, and deliver superior customer value. We excel at solving complex technical business transformation, automation, and connectivity problems that provide maximum value and the best possible outcomes for our customers.

With hundreds of years of in-house experience, we’re the partner of choice for many business transformation projects, working with market leaders who are disrupting and driving transformation across every aspect of modern business.

Find out why leading technology companies partner with Bits In Glass, including Appian (Business Process Management), MuleSoft (API-Led Systems Integration), and Blue Prism (Robotic Process Automation).

For more information about Bits In Glass, visit and follow us on LinkedIn, Twitter, or Instagram.