Ways to Start a Process

Overview

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.

Starting a Process from Tempo or Sites

If you want one of your application users to be able to initiate a process when appropriate, like creating a new service request or updating the status of a service request, the process model should be exposed as an application action or a related action.

Actions should be used when an application user needs to create new data in your application, or they need to initiate a process that isn't related to a specific data point. Examples include:

  • Opening a new service request in your IT support application
  • Adding a new customer to be onboarded by your organization in your Customer Onboarding app
  • Starting your company-wide annual performance review process that will task every user in the organization with a task to fill out their annual self-assessment

Related actions should used when an application user needs to take action on a specific record. Examples include:

  • Updating the status of your service request to IT support to "Closed" because you realized you realized your user error and there's no IT response necessary
  • Adding documents that are related to one of your customers that are represented in your "Customer" record type

Exposing actions and related actions depends on what end-user environment you'd like to use: Appian Tempo, Appian Sites, or embedding your Appian forms in your own web applications.

Learn more:

Starting a Process from a Process

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:

  • Sub-Process - The Sub-Process Activity is used to launch sub-processes 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. Sub-processes 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 immediately 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.

Comparing Ways to Start a Process from a Process

Attributes Sub-Process (Synchronous) Sub-Process (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 Not followed Not followed
Performance Under High Load Medium Medium Good Poor
Quick Tasks Shared Not shared Not shared Not shared

Common Use Cases

Use Case Best Way to Start Process Why?
Using the Results of a Sub-Process Sub-Process (Synchronous) Sub-Process (Synchronous) gives the designer an easy way to map process variables of the sub-process to ones in the current process.
Chaining to a User Input Task Sub-Process (Synchronous) Sub-Process (Synchronous) is the only method that can follow activity chaining into the sub-process. Following an activity chain into a sub-process will continue to add to the number of unattended nodes that exists between two (attended) activity-chained tasks. See Activity-Chaining into a Sub-Process Activity for more information about activity chaining.
Reporting on Asynchronous Sub-Processes Sub-Process (Asynchronous) When you want to start sub-processes asynchronously and have the sub-processes show up in process reports for the current process you must use Sub-Process (Asynchronous). This is because other asynchronous methods don't guarantee the sub-process 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 sub-processes 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 that no use cases for starting processes via process messaging are listed. This is because the Start Process smart service is equivalent or better than process messaging in every category.

See also:

Starting a Process from an Interface

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 Related Actions: A configuration on records to a start process within the context of a record view. Use this for processes of any sort that are related to an entire record instance.

Behavior a!startProcess a!startProcessLink Record Related Action
Pass in data to process Yes Yes Yes
Show start and chained forms No Yes Yes
Configure in any interface Yes Yes No
Maintain original interface state after process starts Yes No No
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

Starting a Process from Outside Appian

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.

Automatically Starting a Process

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:

  • If you had an Appian application for managing employee timesheets, you might want to run a process every Friday morning that found who hasn't submitted their timesheet yet and send those employees a reminder email.
  • If all of your Appian user accounts are based on your company's company-wide Active Directory or LDAP system, you might need to periodically sync the information between that system and Appian.

Learn more about configuring scheduled processes on the process Start Event page.

FEEDBACK