How to Create Flexible Processes

Appian Max Team — Tue, 23 Apr 2024 13:12:00 GMT

Current Revision posted to Guide by Appian Max Team on 4/23/2024 1:12:00 PM

Skills Covered

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.

Legacy Design Pattern

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:

Memory - this parent process instance will be active and its memory in the environment until the full workflow is complete, a timeline the designer cannot control.
Model size - as more functionality is added, this process model will continue to grow over time, which is difficult to maintain.
Backwards compatibility - subsequent releases that change the model have to account for active instances of this version of the model since it lives for so long.
Restarting instances - there is no way to start a process at approval step 1 or approval step 2 when the need arises, as the sub-processes are not independent.

However, designers can construct their process design to avoid these types of problems by planning ahead and using some of the strategies outlined below.

Asynchronous Process Linking

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:

Breaks up a large and sequential process model into a series of smaller standalone models.
Results in a better overall memory profile.
Gives more flexibility for making changes in future releases of the application.
Makes reading the process sizing tab within the Health Check simpler since there is only one active instance per request workflow without the parent model that orchestrates the workflow.

Restartable Processes

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:

Gives flexibility when resolving issues with active processes in Production.
Allows process instances to be created or restarted at the correct workflow step based on database data.
Assists in migrating process instances from one Appian environment to another.
Helps developers test that all data is written correctly to the database during application development.

Router Process Model

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:

Allows for dynamic routing of workflows based on rules
Simplifies process model changes required for workflow updates
Makes restarting processes based on database data even easier since it can be used within the management process model described earlier

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.

Tags: design patterns, Architecture

How to Create Flexible Processes

Kim Day — Tue, 31 Oct 2023 17:16:24 GMT

Revision 9 posted to Guide by Kim Day on 10/31/2023 5:16:24 PM

Skills Covered

This article outlines how to make flexible, reusable, and dynamic workflows in Appian in an effort to make design, maintenance, and change management easy.

This type of design can be used for all applications whether they are data-centric or focus more on a linear task-based workflow.

Legacy Design Pattern

Memory - this parent process instance will be active and its memory in the environment until the full workflow is complete, a timeline the designer cannot control.
Model size - as more functionality is added, this process model will continue to grow over time, which is difficult to maintain.
Backwards compatibility - subsequent releases that change the model have to account for active instances of this version of the model since it lives for so long.
Restarting instances - there is no way to start a process at approval step 1 or approval step 2 when the need arises, as the sub-processes are not independent.

However, designers can construct their process design to avoid these types of problems by planning ahead and using some of the strategies outlined below.

Asynchronous Process Linking

The process linking design pattern is useful because it:

Breaks up a large and sequential process model into a series of smaller standalone models.
Results in a better overall memory profile.
Gives more flexibility for making changes in future releases of the application.
Makes reading the process sizing tab within the Health Check simpler since there is only one active instance per request workflow without the parent model that orchestrates the workflow.

Restartable Processes

The restartable process design pattern is useful because it:

Gives flexibility when resolving issues with active processes in Production.
Allows process instances to be created or restarted at the correct workflow step based on database data.
Assists in migrating process instances from one Appian environment to another.
Helps developers test that all data is written correctly to the database during application development.

Router Process Model

The router model design pattern is useful because it:

Allows for dynamic routing of workflows based on rules
Simplifies process model changes required for workflow updates
Makes restarting processes based on database data even easier since it can be used within the management process model described earlier

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.

Tags: design patterns, Architecture

How to Create Flexible Processes

joel.larin — Thu, 08 Jun 2023 16:26:32 GMT

Revision 8 posted to Guide by joel.larin on 6/8/2023 4:26:32 PM

Skills Covered

This article outlines how to make flexible, reusable, and dynamic workflows in Appian in an effort to make design, maintenance, and change management easy.

This type of design can be used for all applications whether they are data-centric or focus more on a linear task-based workflow.

Legacy Design Pattern

Memory - this parent process instance will be active and its memory in the environment until the full workflow is complete, a timeline the designer cannot control.
Model size - as more functionality is added, this process model will continue to grow over time, which is difficult to maintain.
Backwards compatibility - subsequent releases that change the model have to account for active instances of this version of the model since it lives for so long.
Restarting instances - there is no way to start a process at approval step 1 or approval step 2 when the need arises, as the sub-processes are not independent.

However, designers can construct their process design to avoid these types of problems by planning ahead and using some of the strategies outlined below.

Asynchronous Process Linking

The process linking design pattern is useful because it:

Breaks up a large and sequential process model into a series of smaller standalone models.
Results in a better overall memory profile.
Gives more flexibility for making changes in future releases of the application.
Makes reading the process sizing tab within the Health Check simpler since there is only one active instance per request workflow without the parent model that orchestrates the workflow.

Restartable Processes

The restartable process design pattern is useful because it:

Gives flexibility when resolving issues with active processes in Production.
Allows process instances to be created or restarted at the correct workflow step based on database data.
Assists in migrating process instances from one Appian environment to another.
Helps developers test that all data is written correctly to the database during application development.

Router Process Model

The router model design pattern is useful because it:

Allows for dynamic routing of workflows based on rules
Simplifies process model changes required for workflow updates
Makes restarting processes based on database data even easier since it can be used within the management process model described earlier

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.

Tags: Architecture

How to Create Flexible Processes

Devon Lee — Wed, 22 Mar 2023 16:09:46 GMT

Revision 7 posted to Guide by Devon Lee on 3/22/2023 4:09:46 PM

Skills Covered

This article outlines how to make flexible, reusable, and dynamic workflows in Appian in an effort to make design, maintenance, and change management easy.

This type of design can be used for all applications whether they are data-centric or focus more on a linear task-based workflow.

Legacy Design Pattern

Memory - this parent process instance will be active and its memory in the environment until the full workflow is complete, a timeline the designer cannot control.
Model size - as more functionality is added, this process model will continue to grow over time, which is difficult to maintain.
Backwards compatibility - subsequent releases that change the model have to account for active instances of this version of the model since it lives for so long.
Restarting instances - there is no way to start a process at approval step 1 or approval step 2 when the need arises, as the sub-processes are not independent.

However, designers can construct their process design to avoid these types of problems by planning ahead and using some of the strategies outlined below.

Asynchronous Process Linking

The process linking design pattern is useful because it:

Breaks up a large and sequential process model into a series of smaller standalone models.
Results in a better overall memory profile.
Gives more flexibility for making changes in future releases of the application.
Makes reading the process sizing tab within the Health Check simpler since there is only one active instance per request workflow without the parent model that orchestrates the workflow.

Restartable Processes

The restartable process design pattern is useful because it:

Gives flexibility when resolving issues with active processes in Production.
Allows process instances to be created or restarted at the correct workflow step based on database data.
Assists in migrating process instances from one Appian environment to another.
Helps developers test that all data is written correctly to the database during application development.

Router Process Model

The router model design pattern is useful because it:

Allows for dynamic routing of workflows based on rules
Simplifies process model changes required for workflow updates
Makes restarting processes based on database data even easier since it can be used within the management process model described earlier

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.

Tags: Architecture

How to Create Flexible Processes

joel.larin — Wed, 22 Feb 2023 16:04:01 GMT

Revision 6 posted to Guide by joel.larin on 2/22/2023 4:04:01 PM

Skills Covered

This article outlines how to make flexible, reusable, and dynamic workflows in Appian in an effort to make design, maintenance, and change management easy.

This type of design can be used for all applications whether they are data-centric or focus more on a linear task-based workflow.

Legacy Design Pattern

Memory - this parent process instance will be active and its memory in the environment until the full workflow is complete, a timeline the designer cannot control.
Model size - as more functionality is added, this process model will continue to grow over time, which is difficult to maintain.
Backwards compatibility - subsequent releases that change the model have to account for active instances of this version of the model since it lives for so long.
Restarting instances - there is no way to start a process at approval step 1 or approval step 2 when the need arises, as the sub-processes are not independent.

However, designers can construct their process design to avoid these types of problems by planning ahead and using some of the strategies outlined below.

Asynchronous Process Linking

The process linking design pattern is useful because it:

Breaks up a large and sequential process model into a series of smaller standalone models.
Results in a better overall memory profile.
Gives more flexibility for making changes in future releases of the application.
Makes reading the process sizing tab within the Health Check simpler since there is only one active instance per request workflow without the parent model that orchestrates the workflow.

Restartable Processes

The restartable process design pattern is useful because it:

Gives flexibility when resolving issues with active processes in Production.
Allows process instances to be created or restarted at the correct workflow step based on database data.
Assists in migrating process instances from one Appian environment to another.
Helps developers test that all data is written correctly to the database during application development.

Router Process Model

The router model design pattern is useful because it:

Allows for dynamic routing of workflows based on rules
Simplifies process model changes required for workflow updates
Makes restarting processes based on database data even easier since it can be used within the management process model described earlier

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.

Tags: Architecture

How to Create Flexible Processes

joel.larin — Wed, 22 Feb 2023 15:59:39 GMT

Revision 5 posted to Guide by joel.larin on 2/22/2023 3:59:39 PM

Skills Covered

This article outlines how to make flexible, reusable, and dynamic workflows in Appian in an effort to make design, maintenance, and change management easy.

This type of design can be used for all applications whether they are data-centric or focus more on a linear task-based workflow.

Legacy Design Pattern

Memory - this parent process instance will be active and its memory in the environment until the full workflow is complete, a timeline the designer cannot control.
Model size - as more functionality is added, this process model will continue to grow over time, which is difficult to maintain.
Backwards compatibility - subsequent releases that change the model have to account for active instances of this version of the model since it lives for so long.
Restarting instances - there is no way to start a process at approval step 1 or approval step 2 when the need arises, as the sub-processes are not independent.

However, designers can construct their process design to avoid these types of problems by planning ahead and using some of the strategies outlined below.

Asynchronous Process Linking

The process linking design pattern is useful because it:

Breaks up a large and sequential process model into a series of smaller standalone models.
Results in a better overall memory profile.
Gives more flexibility for making changes in future releases of the application.
Makes reading the process sizing tab within the Health Check simpler since there is only one active instance per request workflow without the parent model that orchestrates the workflow.

Restartable Processes

The restartable process design pattern is useful because it:

Gives flexibility when resolving issues with active processes in Production.
Allows process instances to be created or restarted at the correct workflow step based on database data.
Assists in migrating process instances from one Appian environment to another.
Helps developers test that all data is written correctly to the database during application development.

Router Process Model

The router model design pattern is useful because it:

Allows for dynamic routing of workflows based on rules
Simplifies process model changes required for workflow updates
Makes restarting processes based on database data even easier since it can be used within the management process model described earlier

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.

Tags: Architecture

How to Create Flexible Processes

joel.larin — Wed, 22 Feb 2023 15:49:45 GMT

Revision 4 posted to Guide by joel.larin on 2/22/2023 3:49:45 PM

Skills Covered

This article outlines how to make flexible, reusable, and dynamic workflows in Appian in an effort to make design, maintenance, and change management easy.

This type of design can be used for all applications whether they are data-centric or focus more on a linear task-based workflow.

Legacy Design Pattern

Memory - this parent process instance will be active and its memory in the environment until the full workflow is complete, a timeline the designer cannot control.
Model size - as more functionality is added, this process model will continue to grow over time, which is difficult to maintain.
Backwards compatibility - subsequent releases that change the model have to account for active instances of this version of the model since it lives for so long.
Restarting instances - there is no way to start a process at approval step 1 or approval step 2 when the need arises, as the sub-processes are not independent.

However, designers can construct their process design to avoid these types of problems by planning ahead and using some of the strategies outlined below.

Asynchronous Process Linking

The process linking design pattern is useful because it:

Breaks up a large and sequential process model into a series of smaller standalone models.
Results in a better overall memory profile.
Gives more flexibility for making changes in future releases of the application.
Makes reading the process sizing tab within the Health Check simpler since there is only one active instance per request workflow without the parent model that orchestrates the workflow.

Restartable Processes

The restartable process design pattern is useful because it:

Gives flexibility when resolving issues with active processes in Production.
Allows process instances to be created or restarted at the correct workflow step based on database data.
Assists in migrating process instances from one Appian environment to another.
Helps developers test that all data is written correctly to the database during application development.

Router Process Model

The router model design pattern is useful because it:

Allows for dynamic routing of workflows based on rules
Simplifies process model changes required for workflow updates
Makes restarting processes based on database data even easier since it can be used within the management process model described earlier

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.

Tags: Architecture

How to Create Flexible Processes

joel.larin — Tue, 07 Feb 2023 15:12:45 GMT

Revision 3 posted to Guide by joel.larin on 2/7/2023 3:12:45 PM

Skills Covered

This article outlines how to make flexible, reusable, and dynamic workflows in Appian in an effort to make design, maintenance, and change management easy.

This type of design can be used for all applications whether they are data-centric or focus more on a linear task-based workflow.

Legacy Design Pattern

Memory - this parent process instance will be active and its memory in the environment until the full workflow is complete, a timeline the designer cannot control.
Model size - as more functionality is added, this process model will continue to grow over time, which is difficult to maintain.
Backwards compatibility - subsequent releases that change the model have to account for active instances of this version of the model since it lives for so long.
Restarting instances - there is no way to start a process at approval step 1 or approval step 2 when the need arises, as the sub-processes are not independent.

However, designers can construct their process design to avoid these types of problems by planning ahead and using some of the strategies outlined below.

Asynchronous Process Linking

The process linking design pattern is useful because it:

Breaks up a large and sequential process model into a series of smaller standalone models.
Results in a better overall memory profile.
Gives more flexibility for making changes in future releases of the application.
Makes reading the process sizing tab within the Health Check simpler since there is only one active instance per request workflow without the parent model that orchestrates the workflow.

Restartable Processes

The restartable process design pattern is useful because it:

Gives flexibility when resolving issues with active processes in Production.
Allows process instances to be created or restarted at the correct workflow step based on database data.
Assists in migrating process instances from one Appian environment to another.
Helps developers test that all data is written correctly to the database during application development.

Router Process Model

The router model design pattern is useful because it:

Allows for dynamic routing of workflows based on rules
Simplifies process model changes required for workflow updates
Makes restarting processes based on database data even easier since it can be used within the management process model described earlier

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.

Tags: Architecture

How to Create Flexible Processes

joel.larin — Tue, 07 Feb 2023 14:59:31 GMT

Revision 2 posted to Guide by joel.larin on 2/7/2023 2:59:31 PM

Skills Covered

This article outlines how to make flexible, reusable, and dynamic workflows in Appian in an effort to make design, maintenance, and change management easy.

This type of design can be used for all applications whether they are data-centric or focus more on a linear task-based workflow.

Triage by Priority

Legacy Design Pattern

Memory - this parent process instance will be active and its memory in the environment until the full workflow is complete, a timeline the designer cannot control.
Model size - as more functionality is added, this process model will continue to grow over time, which is difficult to maintain.
Backwards compatibility - subsequent releases that change the model have to account for active instances of this version of the model since it lives for so long.
Restarting instances - there is no way to start a process at approval step 1 or approval step 2 when the need arises, as the sub-processes are not independent.

However, designers can construct their process design to avoid these types of problems by planning ahead and using some of the strategies outlined below.

Better Design Patterns

Asynchronous Process Linking

The process linking design pattern is useful because it:

Breaks up a large and sequential process model into a series of smaller standalone models.
Results in a better overall memory profile.
Gives more flexibility for making changes in future releases of the application.
Makes reading the process sizing tab within the Health Check simpler since there is only one active instance per request workflow without the parent model that orchestrates the workflow.

Restartable Processes

The restartable process design pattern is useful because it:

Gives flexibility when resolving issues with active processes in Production.
Allows process instances to be created or restarted at the correct workflow step based on database data.
Assists in migrating process instances from one Appian environment to another.
Helps developers test that all data is written correctly to the database during application development.

Router Process Model

The router model design pattern is useful because it:

Allows for dynamic routing of workflows based on rules
Simplifies process model changes required for workflow updates
Makes restarting processes based on database data even easier since it can be used within the management process model described earlier

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.

Tags: Architecture

How to Create Flexible Processes

joel.larin — Tue, 07 Feb 2023 14:58:46 GMT

Revision 1 posted to Guide by joel.larin on 2/7/2023 2:58:46 PM

Skills Covered

Triage by Priority

This article outlines how to make flexible, reusable, and dynamic workflows in Appian in an effort to make design, maintenance, and change management easy.

This type of design can be used for all applications whether they are data-centric or focus more on a linear task-based workflow.

Legacy Design Pattern

Memory - this parent process instance will be active and its memory in the environment until the full workflow is complete, a timeline the designer cannot control.
Model size - as more functionality is added, this process model will continue to grow over time, which is difficult to maintain.
Backwards compatibility - subsequent releases that change the model have to account for active instances of this version of the model since it lives for so long.
Restarting instances - there is no way to start a process at approval step 1 or approval step 2 when the need arises, as the sub-processes are not independent.

However, designers can construct their process design to avoid these types of problems by planning ahead and using some of the strategies outlined below.

Better Design Patterns

Asynchronous Process Linking

The process linking design pattern is useful because it:

Breaks up a large and sequential process model into a series of smaller standalone models.
Results in a better overall memory profile.
Gives more flexibility for making changes in future releases of the application.
Makes reading the process sizing tab within the Health Check simpler since there is only one active instance per request workflow without the parent model that orchestrates the workflow.

Restartable Processes

The restartable process design pattern is useful because it:

Gives flexibility when resolving issues with active processes in Production.
Allows process instances to be created or restarted at the correct workflow step based on database data.
Assists in migrating process instances from one Appian environment to another.
Helps developers test that all data is written correctly to the database during application development.

Router Process Model

The router model design pattern is useful because it:

Allows for dynamic routing of workflows based on rules
Simplifies process model changes required for workflow updates
Makes restarting processes based on database data even easier since it can be used within the management process model described earlier

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.

Tags: Architecture