Process Step Types

A process is composed of a number of connected steps. A step can be an Activity, an Event, or a Gateway.

In composite APIs, you can use a subset of the process step types. Manual Activity and Subprocess Activity are not available for composite APIs.

The following sections describe the step types in detail.

Table of Contents

• Process Step Types
  • Step Identification
  • Activities
    • Loops
  • Events
    • Start Event
    • Process Flow Events
    • Intermediary Events
    • End Event
  • Gateways

Step Identification

The following settings identify each step of a process, independent of its type:

• Name: The name of the step.
• ID: A generated number used to uniquely identify the step.
• Description: A short description of the step and its purpose.

Activities

Activities are explicit actions undertaken during the execution of a process. They are represented by rectangles. An icon within the rectangle indicates the type of activity.

The name of an activity should express its purpose and consist of a corresponding action and object, for example, Validate request or Execute payment. A subprocess activity should have the same name as the subprocess it invokes. The names of email/notification activities should start with Notify and state the recipients, for example, Notify requester or Notify IT.

Icon	Description
	Simple Activity This activity does not have a specific function or execute a specific action. It is typically used for data mapping or housekeeping tasks such as initializing variables.
	Connector / Composite API Activity This activity is used to integrate with external systems, APIs, or data. It calls a given connector or composite API. Any connector or composite API available in DigitalSuite can be used. The project it belongs to can be imported as a subproject to the project of the calling process as required. It is also possible to use and import one of the pre-built connectors available in the DigitalSuite Connector Library. Any variables needed by the connector or composite API are automatically created as input variables of the activity. The variables of the connector's or composite API's result can be injected as output variables to the activity. This option should be used carefully, since the variables returned by the connector or composite API are often not fully known.
	Email / Notification Activity This activity is used to send information to users by email or mobile push notification in RunMyApp. The receivers may be individual users, or members of given roles or the current lane of the process. The following can be specified: For emails: subject and message; the provider used to send the email; from, reply to, cc, and bcc addresses; priority, content type, and character set; files to be attached. For push notifications: subject, message, and URL to open upon a click by the user. Both emails and notifications can be localized as needed.
	Subprocess Activity This activity is used to launch a subprocess. Any process designed in DigitalSuite can be used as a subprocess by another one. If its project is not yet included in the project the parent process belongs to, it is imported to it as a subproject. A subprocess is always launched synchronously with respect to the parent process, which means that the parent process will only be resumed after the execution of the subprocess. The subprocess can be executed as an independent process or as a nested process. In the latter case, the processes share their execution context with all parameters. This is not recommended except for very specific situations such as using common measures. Even if a subprocess is executed independently, the parent process can pass all or some of its variables to it, and vice versa. All process input variables of the subprocess are automatically created as input variables of the calling activity. The processes can also share their history and uploaded files. The subprocess can be launched with the credentials of the person who launched the parent process (P_Initiator), the person who last carried out an activity in the parent process (P_User), or a given user with the required permissions.
	Manual Activity This activity assigns a manual task to a specific user or to the members of a role, for example, the approval or rejection of a request. The assignee executes the task on a screen of a web interface, which is specified at the activity or determined at runtime. The user's entries in the screen can be injected directly to output variables of the process activity. It is possible to notify the assignees of manual tasks by email or push notification in different languages, to set a priority and deadline for the task, and to assign the members of a specific role as observers.
	Script Activity This activity runs a script. The script can be JavaScript or FreeMarker, or a PDF document can be generated from an XSL file. The file containing the script or XSL needs to be uploaded to DigitalSuite. It can then be referenced by its URL.

Loops

An activity can be executed in a loop. The following types of loop are available:

• While loop: The activity is repeated as long as a given condition is fulfilled or until the maximum number of executions is reached.

• Multi-instance loop: The activity is executed for each value in an array. The executions can be run in parallel or in sequential order (recommended for connector and email/notification activities).

The number of successful iterations of an activity is stored in a process parameter, ${P_index}. This parameter can be used in the activity's input and output variables. For a while loop, output variables are calculated even if the condition is not met. For a multi-instance loop, input and output variables are not calculated for an empty array.

Events

Events signal that something of significance has happened that needs to be dealt with. Every process has a start and one or more end events which are triggered at the beginning and the end. Process flow events are used to pause a process for a given time or until specific conditions are met. Intermediary events can be configured to trigger the execution of alternative process branches in response to a defined situation such as process cancellation, an unrecoverable failure, or the lack of a timely response.

Events are represented by a circle. An icon within the circle indicates the type of event.

Start Event

This event defines how the process is triggered. Start events are represented by a circle with a single, narrow border.

Icon	Description
	Start Event The process is triggered by submitting a form of a web interface or an HTML file available in DigitalSuite, or by a web service call (POST request) from an application. Using a web interface is the most common way to launch a process in DigitalSuite. Internally, the instances of the web interface and the process are linked with each other and thus can share data such as URLs or measures. This can be prohibited by invoking the process through a process listener configured at the web interface.
	Message Start Event The process is triggered when an email is sent to an email address, which depends on the execution mode: process+{customerid}.{processid}@runmyprocess.com for Live mode. process+{customerid}.{processid}.TEST@runmyprocess.com for Test mode. process+{customerid}.{processid}.ACCEPTANCE@runmyprocess.com for Acceptance mode. The fields and data of the email are mapped to process input variables. Before the mapping, the message content can be parsed using one of the formats available for the variables. For immediate identification, the names of message-triggered processes should start with a prefix like EMAIL, for example, EMAIL - Import data from ERP.
	Timer Start Event The process is triggered automatically at a defined frequency as of a given date and time. Launching a process by a timer is possible only in the Live execution mode. By default, timer-triggered processes are launched in the name of the user who last saved the process. However, a different user can be specified in the process configuration. For immediate identification, the names of timer-triggered processes should start with a prefix like BATCH or TIMER followed by the execution frequency, for example, BATCH 2days - Import csv from ERP.
	Conditional Start Event The process is triggered if a condition is met (evaluates to True). The condition is evaluated by a composite API for a given number of times.

Process Flow Events

These events occur in the execution path of the process. They are represented by a circle with a double border.

Icon	Description
	Timer Event The process pauses for a given period of time.
	Conditional Event The process pauses until a condition is met (evaluates to True). The condition is evaluated by a composite API for a given number of times.

Intermediary Events

Intermediary events are special events that occur when something out of the ordinary happens within an activity, for example, a timeout error. These events trigger the execution of an alternative process branch to manage the problem. The alternative branch starts directly at the activity without requiring a corresponding gateway. It can be rejoined with the main process execution path by means of Exclusive Or Join.

In the process design, intermediary events are represented by a small circle with a double border located on a corner of the relevant activity.

Icon	Description
	Error Intermediary Event The alternative branch is followed if the activity fails.
	Timer Intermediary Event The alternative branch is followed if the activity does not complete within the given time. This type of event should be used only with manual and subprocess activities.
	Cancel Intermediary Event The alternative branch is followed if the activity is cancelled. This should be done only with manual activities.

End Event

End events denote the termination of a process. They are represented by a circle with a single, thick border.

Each process must have at least one end event. All execution paths must either rejoin the main process flow or terminate with their own end event.

Gateways

Gateways are the starting or ending points of parallel or alternative execution paths in a process. They are represented by diamonds.

Icon	Description
	And Split This gateway is the starting point for concurrent execution paths in a process. The paths run in parallel and independent of each other. They can be rejoined using an And Join, or each branch can end independently with an end event.
	And Join This gateway rejoins execution paths that have split due to an And Split.
	Exclusive Or Split This gateway is the starting point for mutually exclusive execution paths in a process. Depending on a condition, one of the paths is followed. The paths can be rejoined using an Exclusive Or Join, or each branch can end with an end event.
	Exclusive Or Join This gateway rejoins execution paths that have split due to an Exclusive Or Split gateway or an intermediary event.