Processes orchestrate your workflows and are a key component of your Appian applications. As such, there are a variety of ways in which your processes can be started, depending on your application's needs. This page highlights all the available ways to initiate processes in your application and details when you should consider each approach.
To allow users to initiate different business processes, like creating a new service request or updating the status of a service request, a process model should be exposed as a record action or an application action.
Record actions allow users to take action on a specific record or a list of records. These actions are configured in the record type and can be displayed on record views, the record list, or in your reports and forms using the record action component.
Record actions can allow your users to start processes like:
In addition to record actions, you can also leverage application actions. These actions expose process models in end user interfaces. You can display these actions as a page on your Site or in the Actions tab in Tempo.
Learn more:
Portals can use a!startProcess() in an interface to start a process. However, they cannot use any other method to start a process, such as through a start form or record action.
There are several different ways to launch a process directly from an interface.
a!startProcess: A function that starts a process when triggering an interface reevaluation. Use this for unattended activities related to a specific piece of information on the interface.
a!startProcessLink: A link type that starts a process and navigates the user through any initial chained forms. Use this for taking the user to a process related to a specific piece of information on an interface.
Record Actions: A configuration on a record type that starts a process within the context of a record view or a record list. The process can also be started on a report or form using a record action component. Use this for updating or adding records to your record type.
| Behavior | a!startProcess | a!startProcessLink | Record Action |
|---|---|---|---|
| Pass in data to process | Yes | Yes | Yes |
| Show start and chained forms | No | Yes | Yes |
| Configure in any interface | Yes | Yes | Yes |
| Maintain original interface state after process starts | Yes | No | Yes* |
| Use for file upload cases | No | Yes | Yes |
| Display custom banner on submit | No | Yes | No |
| Save URL as bookmark | No | No | Yes |
| Use in a Web API | Yes | No | No |
| Access process data on completion | Yes | No | No |
| Write custom error handling | Yes | No | No |
*This is only true when a record action is opened and submitted in a Dialog Box. For more information, see the a!refreshVariable
Appian offers several ways to start a new process from within a running process. The best choice will depend on your use case. The following article will detail the differences between these and provide common uses cases when each is appropriate.
The ways to start a new process from within a running process are:
Subprocess: A smart service that is used to launch subprocesses from within your current process. It links the two published process models through a parent-child relationship and allows you to transfer data between them. The parent and child processes each contain references to the other. Subprocesses can be run either asynchronously or synchronously.
Start Process Smart Service: A smart service that allows you to initiate another process from your current process. The new process is started asynchronously and the process flow of the current process continues after the new process starts.
Process Messaging: The Send Event and End Event activities can trigger the starting of a new process if that process model's start node is configured to receive messages. Note in the table below that the Start Process smart service is equivalent or better than process messaging in every category.
| Attributes | Subprocess (Synchronous) | Subprocess (Asynchronous) | Start Process Smart Service | Process Messaging |
|---|---|---|---|---|
| Synchronicity | Synchronous | Asynchronous | Asynchronous | Asynchronous |
| Parent-Child Relationship | Yes | Yes | No | No |
| Process Variables | Can be passed by reference | Can be passed by reference | Cannot be passed by reference | Cannot be passed by reference |
| Process Outputs | Available | Not available | Not available | Not available |
| Process Reports of Parent | Can access | Can access | Cannot access | Cannot access |
| Execution Engine Balancing | Same Engine | Same Engine | Balanced | Balanced |
| Model to Start | Defined statically | Defined statically | Defined dynamically | Defined statically |
| Activity Chaining | Followed | Not followed | Followed* | Not followed |
| Performance Under High Load | Medium | Medium | Good | Poor |
| Quick Tasks | Shared | Not shared | Not shared | Not shared |
*Will follow chaining in the new process until chaining ends, then the parent process resumes (even if the new process has not finished)
| Use Case | Best Way to Start Process | Why? |
|---|---|---|
| Using the Results of a Subprocess | Subprocess (Synchronous) | Subprocess (Synchronous) gives the designer an easy way to map process variables of the subprocess to ones in the current process. |
| Chaining to a User Input Task | Subprocess (Synchronous) | Subprocess (Synchronous) is the only method that can follow activity chaining into the subprocess. Following an activity chain into a subprocess will continue to add to the number of unattended nodes that exists between two (attended) activity-chained tasks. See Activity-Chaining into a Subprocess Activity for more information about activity chaining. |
| Reporting on Asynchronous Subprocesses | Subprocess (Asynchronous) | When you want to start subprocesses asynchronously and have the subprocesses show up in process reports for the current process you must use Subprocess (Asynchronous). This is because other asynchronous methods don't guarantee the subprocess will be on the same engine as the current process. |
| Starting Multiple Processes at Once | Start Process Smart Service | When you want to start multiple subprocesses at the same time you should use Multiple Node Instances (MNI) functionality on the Start Process smart service. The main reason for doing this is that the Start Process smart service will manage load on the system by spreading the newly started processes across all execution engines. |
Note: Note that no use cases for starting processes via process messaging are listed. This is because the Start Process smart service is equivalent to or better than process messaging in every category.
See also:
Appian isn't the only system in your enterprise, and because of this, you might eventually need to initiate Appian processes from one of those other systems.
There are three different ways to initiate Appian processes from other systems:
When to use each of these methods is outlined in the Choosing the Right Type of Integration page.
Processes don't always need an user interaction or another system to initiate them. You can also configure process models to automatically start on a particular date and time or a scheduled interval.
Some examples of this include:
Learn more about configuring scheduled processes on the process Start Event page.
Ways to Start a Process
