This article outlines how to make flexible, reusable, and dynamic workflows in Appian in an effort to make design, maintenance, and change management easy.
Creating Memory Efficient Models covers many useful strategies for designing process models that follow best practices. This article will dive deeper into design patterns that will assist with creating workflows with many sequential steps. Creating an entire workflow into a single process model has negative memory implications, is difficult to maintain, and can result in backwards compatibility issues for future releases. Below are some strategies for designing processes that alleviate those risks.
This type of design can be used for all applications whether they are data-centric or focus more on a linear task-based workflow.
The image below shows a simple example of a model that contains all parts of a workflow. Designing all parts of the workflow into a single process provides a readable picture of the overall workflow, but this type of design introduces problems, even though it is nicely broken into sub-processes:
However, designers can construct their process design to avoid these types of problems by planning ahead and using some of the strategies outlined below.
Any workflow that requires multiple touches or approvals from different users has logical break points that can be leveraged in the model design. At the point of a hand-off, call the next step in the flow as an asynchronous process model so that the first model can complete and be archived/deleted, while the rest of the workflow continues. Note that the Sub-Process node will keep the next process on the same execution engine, but it is convenient when developing and monitoring instances since the sub-process can be opened directly from the parent within the modeler. For scenarios when a parent process starts multiple child processes, use the Start Process node to load balance across execution engines. Using the same example as used for explaining the legacy design pattern, see the image below for an example model that uses this alternate design for the submission step:
After the submission comes an approval and based on the result of that approval, the process that comes next in the workflow will depend on the decision from the approver. While a send-back in a process model is usually designed as a path that returns to a previous node in the model, this design pattern calls that first step in a send-back loop by continuing forward, starting a new instance of the first step. With some simple updates to the submission model, it can handle the scenario of a first time request or a send-back. The image below depicts how this design pattern can handle the described scenario:
The process linking design pattern is useful because it:
When using a data driven design, there are more opportunities for developers to design with flexibility in mind. Consider the example above. The request data is likely passed from the submission model to the approval model, but the approval model could also be adapted to read from a data source if only the request id, not all the request data, is passed to it. This provides utility when a support engineer needs to make a change and restart a task or when process instances need to be migrated from one Appian environment to another. These are use cases that are hard to meet with large process models containing all the workflow steps, but easy to meet with these types of flexible designs. The image below shows that the model will go directly to the user input task if all the data is passed as parameters, but will call a script task to query the data if those parameters are not passed:
If restarting a large number of process instances from the database, a management process model will need to determine what model each request needs initiated. Only the ids and statuses are needed from the database to do this and the new process instances can be started by simply passing the request id. This type of model can be created once and used in a variety of scenarios. The image below shows an example management model that is starting process instances based on data in the database:
The restartable process design pattern is useful because it:
To be even more flexible, a helper process model can be used to dynamically choose what process model to start next based on rules and not explicit flow in the process model. This is particularly useful when workflows change in the middle of a running process, determined by a data driven workflow that can be managed by end-users. Expressions rules will determine what process to start next via the Start Process Node, based on the data for the request. This keeps reusable logic contained in a single process that can be called in multiple places. The image below shows an example process model that does this:
The router model would be called at the end of each process in the workflow as shown below. Note that the logic regarding which step occurs next does not have to be put into the approval model anymore. This makes updates to running instances easier because a deployed change to the router model will be used by all active instances, which can be extremely powerful. The images below show the router model being used in the same example scenario described in the above sections:
The router model design pattern is useful because it:
Using all or a subset of the design patterns outlined above will give developers far more flexibility managing live applications and planning for subsequent releases.