Basic properties

The basic properties for a start event are:

Form name

An optionalform can be used to begin a process. The form must exist within the same project as the process definition to be selected. Select a form from the dropdown, else create a new form using the+ symbol.

Once a form has been selected, it can be edited using theOpen Form symbol.

Mapping type

The mapping type sets how data is passed between the start event and the process. There arefive options for how to send this data. The default value isDon’t map variables. For form widgets and form variables you can add static values. For example you can pass a form variable calledpath which can be a file location or URL.

Start events are displayed as a single thin circle without an icon inside.

An example of the XML of a start event without a form defined is:

<bpmn2:startEvent name="FormStart_4"><bpmn2:outgoing>SequenceFlow_1</bpmn2:outgoing></bpmn2:startEvent>

An example of the XML of a start event with a form defined is:

<bpmn2:startEvent name="FormStart_4" activiti:formKey="form-4ccd023b-d607-4cab-8623-da4c87dd9611"><bpmn2:outgoing>SequenceFlow_1</bpmn2:outgoing></bpmn2:startEvent>

Note: Theactiviti:formKey is theid of the form used to start the process.

Basic properties

The basic properties for an error start event are:

Form name

An optionalform can be used to begin a process. The form must exist within the same project as the process definition to be selected. Select a form from the dropdown, else create a new form using the+ symbol.

Once a form has been selected, it can be edited using theOpen Form symbol.

Mapping type

The mapping type sets how data is passed between the error start event and the process. There arefive options for how to send this data. The default value isSend no variables.

Error

An error needs to be defined for the error start event to catch. A previously createdError can be selected from the dropdown in its properties, or a new one created using the+ symbol. AnError name andError code can then be set.

Error events are used to model an exception in a business process. Errors are thrown by error end events and caught by error start events and error boundary events.

TheerrorRef property in theerrorEventDefinition of an error event element will match against theid of an error when viewing theXML Editor.

Error events are displayed as a lightning bolt icon inside different shapes that differentiate between the event types. A solid lightning bolt represents a throwing event, whilst a hollow lightning bolt represents a catching event.

To create a new error use the+ symbol against an error event such as a start error event, or make sure no BPMN element is selected by clicking on a blank section of the process canvas and theEdit Errors button will be visible in the right-hand properties panel.

Error start events are displayed as a single thin circle with a hollow lightning bolt icon inside.

An example of the XML of an error start event is:

<bpmn2:startEvent><bpmn2:errorEventDefinition errorRef="Error_0vbkbeb" /></bpmn2:startEvent>

An example of the XML of an error is:

<bpmn2:error name="payment-failed-error" errorCode="404" />

Basic properties

The basic properties for a message start event are:

Form name

An optionalform can be used to begin a process. The form must exist within the same project as the process definition to be selected. Select a form from the dropdown, else create a new form using the+ symbol.

Once a form has been selected, it can be edited using theOpen Form symbol.

Mapping type

The mapping type sets how data is passed between the message start event and the process. There arefive options for how to send this data. The default value isSend no variables.

Message

A message needs to be defined for the message start event to catch when it is thrown. A previously createdMessage can be selected from the dropdown in its properties, or a new one created using the+ symbol. AMessage name and payload can then be set.

Message

Messages have a name and contain a payload. They are sent by message throwing events and received by message catching events in a 1:1 relationship between throw events and catch events. Messages contain a payload known as a message payload and can be passed between scopes, for example between two different process definitions within the same diagram that are separated by differentpools.

The messageid property of a message is matched against themessageRef property in the corresponding throw and catch message elements when viewing theXML Editor.

To create a new message use the+ symbol against a message event such as a message boundary event, or make sure no BPMN element is selected by clicking on a blank section of the process canvas and theEdit Messages button will be visible in the right-hand properties panel.

Message events are displayed as an envelope icon inside different shapes that differentiate between the event types. A solid envelope represents a throwing event, whilst a hollow envelope represents a catching event.

Message payloads

Message payloads contain a set of values that are sent from a throwing event and received by a catching event.

Message payloads can only be created on a message throw event and contain one or more properties that have aname,type andvalue. The property types for payloads are:

The receiving message catch event is then used to map the received values in the payload to process variables in its own scope.

Message payload mappings can be viewed in theExtensions Editor of a process diagram. Throwing events are mapped asinputs and catching events are mapped asoutputs from an event.

Correlation keys

Message events can optionally contain a correlation key. If a correlation key is present then when a message is thrown it uses theactiviti:correlationKey value and themessageRef of the throwing event to match against the same two properties in a catching event. If only one property is matched then the message will not be caught.

Using aprocess variable for the correlation key in a throwing event and a static value for its corresponding catching event allows for the message to only be caught in specific circumstances.

Note: Message start events cannot contain a correlation key unless they are used in asub process.

Message flows

When messages are used between two differentpools the sequence flow that connects them is a dotted line called a message flow. The message flow is part of thecollaboration element in the XML created by introducing a pool. Message flows reference the throwing message event as thesourceRef and the catching message event as thetargetRef.

Message start events are displayed as a single thin circle with a hollow envelope icon inside.

An example of the XML of a message start event is:

<bpmn2:startEvent><bpmn2:outgoing>SequenceFlow_1</bpmn2:outgoing><bpmn2:messageEventDefinition messageRef="Message_15xakkk" /></bpmn2:startEvent>

An example of the XML of a message is:

<bpmn2:message name="Message_15xakkk" />

An example of the XML of a message payload is:

    "mappings": {        "EndEvent_0ss2fp3": {            "inputs": {                "name": {                    "type": "variable",                    "value": "username"                },                "order-number": {                    "type": "value",                    "value": 1459283                }            }        }    },

An example of the XML of a message with a correlation key is:

<bpmn2:endEvent><bpmn2:incoming>SequenceFlow_8</bpmn2:incoming><bpmn2:messageEventDefinition messageRef="Message_1hxecs2" activiti:correlationKey="${userId}" />

In this example the message will only be caught if a catching event has amessageRef ofMessage_1hxecs2 and anactiviti:correlationKey that matches the value ofuserId.

An example of the XML of a message flow is:

<bpmn2:collaboration><bpmn2:participant processRef="Process_1d9yxsm" /><bpmn2:participant processRef="Process_1piiyp4" /><bpmn2:messageFlow sourceRef="Event_00acemq" targetRef="Event_13u5jtf" /></bpmn2:collaboration>

Basic properties

The basic properties for a signal start event are:

Signal

A signal needs to be defined for the signal start event to catch. A previously usedSignal can be selected from the dropdown in its properties, or a new one created using the+ symbol. ASignal name can then be set.

Signals can be restricted to the process instance they are thrown in, or be global in scope. The scope of a global signal is restricted to the project they are used in.

Signal events can be either catching or throwing. A throwing signal event will emit a signal when it is reached in a process instance that will be picked up by any catching signal event with a matching signal name. Signals can be restricted to the process instance they are thrown in, or be global in scope. The scope of a global signal is restricted to the project they are used in.

Theid of a signal will match against thesignalRef of a catching or throwing event.

Signal events are displayed as a triangle icon inside different shapes that differentiate between the event types. A solid triangle represents a throwing event, whilst a hollow triangle represents a catching event.

Signal start events are displayed as a single thin circle with a hollow triangle icon inside.

An example of the XML of a signal start event is:

<bpmn2:startEvent><bpmn2:outgoing>SequenceFlow_1</bpmn2:outgoing> <bpmn2:signalEventDefinition signalRef="Signal_0hnsd2r" /></bpmn2:startEvent>

An example of the XML of a signal with a global scope is:

<bpmn2:signal name="Signal_0hnsd2r" />

An example of the XML of a signal with a process instance scope is:

<bpmn2:signal name="Signal_0hnsd2r" activiti:scope="processInstance" />

Basic properties

The basic properties for a timer start event are:

Form name

An optionalform can be used to begin a process. The form must exist within the same project as the process definition to be selected. Select a form from the dropdown, else create a new form using the+ symbol.

Once a form has been selected, it can be edited using theOpen Form symbol.

Mapping type

The mapping type sets how data is passed between the timer start event and the process. There arefive options for how to send this data. The default value isSend no variables.

Timer

A choice of timer must be set for timer start events, based on aCycle,Date orDuration.

Timer events are used to influence events at specific times, after a set amount of time has passed or at intervals. All timer events use the international standardISO 8601 for specifying time formats.

Note: All properties withintimerEventDefinition can accept process variables as their values as long as they are in ISO 8601 or cron expression format.

Timer events are displayed as a clock icon inside different shapes that differentiate between the event types.

timeDate

ThetimeDate property for timer events defines a specific date and time in ISO 8601 format for when the trigger will be fired and can include a specified time zone.

The following is an example of thetimerEventDefinition using atimeDate:

• 2017-05-17 represents the 17th May 2017 inYYYY-MM-DD format
• T12:42:23 represents the time of 12:42:23 inhh:mm:ss format
• Z represents that the time format is in UTC (Coordinated Universal Time). The time can also contain UTC offsets such as+01 for an hour ahead of UTC. When an offset is defined theZ is not required, for example:T12:42:23+01

timeDuration

ThetimeDuration property for timer events defines how long a timer should wait in ISO 8601 format before the trigger is fired.

The following are the letters used to refer to duration:

timeCycle

ThetimeCycle property for timer events defines intervals for the trigger to fire at. Intervals can be defined using the time intervals that adhere to the ISO 8601 standard or by using cron expressions.

Time intervals

Time intervals use the syntaxR/ to set a number of repetitions, for exampleR5/ would repeat five times.

Following the repetition, a duration can be set for when the repetition occurs, for exampleR5/PT10H would repeat every 10 hours, five times.

Note The duration uses the same format as fortimeDuration.

An optional end date can also be set after the duration and separated by a/.

Note: The end date uses the same format as fortimeDate.

Cron expression intervals

Cron expressions can also be used to define repeating triggers for timer events.

Timer start events are displayed as a single thin circle with a clock icon inside.

An example of the XML of a timer start event is:

<bpmn2:startEvent>    <bpmn2:outgoing>SequenceFlow_1</bpmn2:outgoing>    <timerEventDefinition>        <timeCycle xsi:type="bpmn2:tFormalExpression">R10/2020-12-10T13:00/PT12H</timeCycle>    </timerEventDefinition></bpmn2:startEvent>

Note: This will start the process 10 times, at 12 hour intervals starting on the 10th December 2020.

An example of the XML fortimeDate is:

<bpmn2:timerEventDefinition>   <bpmn2:timeDate xsi:type="bpmn2:tFormalExpression">2017-05-17T12:42:23Z</bpmn2:timeDate></bpmn2:timerEventDefinition>

An example of the XML fortimeDuration is:

<bpmn2:timerEventDefinition>  <bpmn2:timeDuration xsi:type="bpmn2:tFormalExpression">P5D</bpmn2:timeDuration></bpmn2:timerEventDefinition>

Note: This represents a duration of 5 days.

An example of the XML fortimeCycle using time interval syntax is:

<bpmn2:timerEventDefinition>  <bpmn2:timeCycle xsi:type="bpmn2:tFormalExpression">R3/PT30M</bpmn2:timeCycle></bpmn2:timerEventDefinition>

Note: This represents three repetitions every 30 minutes.

An example of the XML fortimeCycle using a cron expression is:

<bpmn2:timerEventDefinition>  <bpmn2:timeCycle>0 0/5 * * * ?</bpmn2:timeCycle></bpmn2:timerEventDefinition>

Note: This represents a trigger firing every 5 minutes beginning at the top of the hour.

Basic properties

The basic properties for an end event are:

End events are displayed as a single thick circle without an icon inside.

An example of the XML of an end event is:

<bpmn2:endEvent>    <bpmn2:incoming>SequenceFlow_1</bpmn2:incoming></bpmn2:endEvent>

Basic properties

The basic properties for an error end event are:

Error

An error needs to be defined for the error end event to throw. A previously createdError can be selected from the dropdown in its properties, or a new one created using the+ symbol. AnError name andError code can then be set.

Error events are used to model an exception in a business process. Errors are thrown by error end events and caught by error start events and error boundary events.

TheerrorRef property in theerrorEventDefinition of an error event element will match against theid of an error when viewing theXML Editor.

Error events are displayed as a lightning bolt icon inside different shapes that differentiate between the event types. A solid lightning bolt represents a throwing event, whilst a hollow lightning bolt represents a catching event.

To create a new error use the+ symbol against an error event such as a start error event, or make sure no BPMN element is selected by clicking on a blank section of the process canvas and theEdit Errors button will be visible in the right-hand properties panel.

Error end events are displayed as a single thick circle with a solid lightning bolt icon inside.

An example of the XML of an error end event is:

<bpmn2:endEvent>    <bpmn2:incoming>SequenceFlow_8</bpmn2:incoming>    <bpmn2:errorEventDefinition errorRef="Error_3vbkafg" /></bpmn2:endEvent>

An example of the XML of an error is:

<bpmn2:error name="payment-failed-error" errorCode="404" />

Basic properties

The basic properties for a message end event are:

Message

A message needs to be defined for the message end event to send. A previously createdMessage can be selected from the dropdown in its properties, or a new one created using the+ symbol. AMessage name and payload can then be set.

Message

Messages have a name and contain a payload. They are sent by message throwing events and received by message catching events in a 1:1 relationship between throw events and catch events. Messages contain a payload known as a message payload and can be passed between scopes, for example between two different process definitions within the same diagram that are separated by differentpools.

The messageid property of a message is matched against themessageRef property in the corresponding throw and catch message elements when viewing theXML Editor.

To create a new message use the+ symbol against a message event such as a message boundary event, or make sure no BPMN element is selected by clicking on a blank section of the process canvas and theEdit Messages button will be visible in the right-hand properties panel.

Message events are displayed as an envelope icon inside different shapes that differentiate between the event types. A solid envelope represents a throwing event, whilst a hollow envelope represents a catching event.

Message payloads

Message payloads contain a set of values that are sent from a throwing event and received by a catching event.

Message payloads can only be created on a message throw event and contain one or more properties that have aname,type andvalue. The property types for payloads are:

The receiving message catch event is then used to map the received values in the payload to process variables in its own scope.

Message payload mappings can be viewed in theExtensions Editor of a process diagram. Throwing events are mapped asinputs and catching events are mapped asoutputs from an event.

Correlation keys

Message events can optionally contain a correlation key. If a correlation key is present then when a message is thrown it uses theactiviti:correlationKey value and themessageRef of the throwing event to match against the same two properties in a catching event. If only one property is matched then the message will not be caught.

Using aprocess variable for the correlation key in a throwing event and a static value for its corresponding catching event allows for the message to only be caught in specific circumstances.

Note: Message start events cannot contain a correlation key unless they are used in asub process.

Message flows

When messages are used between two differentpools the sequence flow that connects them is a dotted line called a message flow. The message flow is part of thecollaboration element in the XML created by introducing a pool. Message flows reference the throwing message event as thesourceRef and the catching message event as thetargetRef.

Message end events are displayed as a single thick circle with a solid envelope icon inside.

An example of the XML of a message end event is:

<bpmn2:endEvent><bpmn2:incoming>SequenceFlow_1</bpmn2:incoming><bpmn2:messageEventDefinition messageRef="Message_45sdihj" /></bpmn2:endEvent>

An example of the XML of a message is:

<bpmn2:message name="Message_15xakkk" />

An example of the XML of a message payload is:

    "mappings": {        "EndEvent_0ss2fp3": {            "inputs": {                "name": {                    "type": "variable",                    "value": "username"                },                "order-number": {                    "type": "value",                    "value": 1459283                }            }        }    },

An example of the XML of a message with a correlation key is:

<bpmn2:endEvent><bpmn2:incoming>SequenceFlow_8</bpmn2:incoming><bpmn2:messageEventDefinition messageRef="Message_1hxecs2" activiti:correlationKey="${userId}" />

In this example the message will only be caught if a catching event has amessageRef ofMessage_1hxecs2 and anactiviti:correlationKey that matches the value ofuserId.

An example of the XML of a message flow is:

<bpmn2:collaboration><bpmn2:participant processRef="Process_1d9yxsm" /><bpmn2:participant processRef="Process_1piiyp4" /><bpmn2:messageFlow sourceRef="Event_00acemq" targetRef="Event_13u5jtf" /></bpmn2:collaboration>

Basic properties

The basic properties for a terminate end event are:

Terminate end events are displayed as a single thick circle with a solid circle inside.

An example of the XML of a terminate end event is:

<bpmn2:endEvent><bpmn2:incoming>SequenceFlow_1</bpmn2:incoming><bpmn2:terminateEventDefinition/></bpmn2:endEvent>

Basic properties

The basic properties for a message intermediate catch event are:

Message

A message needs to be defined for the message intermediate catch event to catch. A previously createdMessage can be selected from the dropdown in its properties, or a new one created using the+ symbol. AMessage name and payload can then be set.

Message

Messages have a name and contain a payload. They are sent by message throwing events and received by message catching events in a 1:1 relationship between throw events and catch events. Messages contain a payload known as a message payload and can be passed between scopes, for example between two different process definitions within the same diagram that are separated by differentpools.

The messageid property of a message is matched against themessageRef property in the corresponding throw and catch message elements when viewing theXML Editor.

To create a new message use the+ symbol against a message event such as a message boundary event, or make sure no BPMN element is selected by clicking on a blank section of the process canvas and theEdit Messages button will be visible in the right-hand properties panel.

Message events are displayed as an envelope icon inside different shapes that differentiate between the event types. A solid envelope represents a throwing event, whilst a hollow envelope represents a catching event.

Message payloads

Message payloads contain a set of values that are sent from a throwing event and received by a catching event.

Message payloads can only be created on a message throw event and contain one or more properties that have aname,type andvalue. The property types for payloads are:

The receiving message catch event is then used to map the received values in the payload to process variables in its own scope.

Message payload mappings can be viewed in theExtensions Editor of a process diagram. Throwing events are mapped asinputs and catching events are mapped asoutputs from an event.

Correlation keys

Message events can optionally contain a correlation key. If a correlation key is present then when a message is thrown it uses theactiviti:correlationKey value and themessageRef of the throwing event to match against the same two properties in a catching event. If only one property is matched then the message will not be caught.

Using aprocess variable for the correlation key in a throwing event and a static value for its corresponding catching event allows for the message to only be caught in specific circumstances.

Note: Message start events cannot contain a correlation key unless they are used in asub process.

Message flows

When messages are used between two differentpools the sequence flow that connects them is a dotted line called a message flow. The message flow is part of thecollaboration element in the XML created by introducing a pool. Message flows reference the throwing message event as thesourceRef and the catching message event as thetargetRef.

Message intermediate catching events are displayed as two thin concentric circles with a hollow envelope icon inside.

An example of the XML of a message intermediate catch events is:

<bpmn2:intermediateCatchEvent><bpmn2:incoming>SequenceFlow_5</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_6</bpmn2:outgoing>    <bpmn2:messageEventDefinition messageRef="Message_6" /></bpmn2:intermediateCatchEvent>

An example of the XML of a message is:

<bpmn2:message name="Message_15xakkk" />

An example of the XML of a message payload is:

    "mappings": {        "EndEvent_0ss2fp3": {            "inputs": {                "name": {                    "type": "variable",                    "value": "username"                },                "order-number": {                    "type": "value",                    "value": 1459283                }            }        }    },

An example of the XML of a message with a correlation key is:

<bpmn2:endEvent><bpmn2:incoming>SequenceFlow_8</bpmn2:incoming><bpmn2:messageEventDefinition messageRef="Message_1hxecs2" activiti:correlationKey="${userId}" />

In this example the message will only be caught if a catching event has amessageRef ofMessage_1hxecs2 and anactiviti:correlationKey that matches the value ofuserId.

An example of the XML of a message flow is:

<bpmn2:collaboration><bpmn2:participant processRef="Process_1d9yxsm" /><bpmn2:participant processRef="Process_1piiyp4" /><bpmn2:messageFlow sourceRef="Event_00acemq" targetRef="Event_13u5jtf" /></bpmn2:collaboration>

Basic properties

The basic properties for a message intermediate throw event are:

Message

A message needs to be defined for the message intermediate throw event to catch. A previously createdMessage can be selected from the dropdown in its properties, or a new one created using the+ symbol. AMessage name and payload can then be set.

Message

Messages have a name and contain a payload. They are sent by message throwing events and received by message catching events in a 1:1 relationship between throw events and catch events. Messages contain a payload known as a message payload and can be passed between scopes, for example between two different process definitions within the same diagram that are separated by differentpools.

The messageid property of a message is matched against themessageRef property in the corresponding throw and catch message elements when viewing theXML Editor.

To create a new message use the+ symbol against a message event such as a message boundary event, or make sure no BPMN element is selected by clicking on a blank section of the process canvas and theEdit Messages button will be visible in the right-hand properties panel.

Message events are displayed as an envelope icon inside different shapes that differentiate between the event types. A solid envelope represents a throwing event, whilst a hollow envelope represents a catching event.

Message payloads

Message payloads contain a set of values that are sent from a throwing event and received by a catching event.

Message payloads can only be created on a message throw event and contain one or more properties that have aname,type andvalue. The property types for payloads are:

The receiving message catch event is then used to map the received values in the payload to process variables in its own scope.

Message payload mappings can be viewed in theExtensions Editor of a process diagram. Throwing events are mapped asinputs and catching events are mapped asoutputs from an event.

Correlation keys

Message events can optionally contain a correlation key. If a correlation key is present then when a message is thrown it uses theactiviti:correlationKey value and themessageRef of the throwing event to match against the same two properties in a catching event. If only one property is matched then the message will not be caught.

Using aprocess variable for the correlation key in a throwing event and a static value for its corresponding catching event allows for the message to only be caught in specific circumstances.

Note: Message start events cannot contain a correlation key unless they are used in asub process.

Message flows

When messages are used between two differentpools the sequence flow that connects them is a dotted line called a message flow. The message flow is part of thecollaboration element in the XML created by introducing a pool. Message flows reference the throwing message event as thesourceRef and the catching message event as thetargetRef.

Message intermediate throwing events are displayed as two thin concentric circles with a solid envelope icon inside.

An example of the XML of a message intermediate throw events is:

<bpmn2:intermediateThrowEvent><bpmn2:incoming>SequenceFlow_5</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_6</bpmn2:outgoing>    <bpmn2:messageEventDefinition messageRef="Message_6" /></bpmn2:intermediateThrowEvent>

An example of the XML of a message is:

<bpmn2:message name="Message_15xakkk" />

An example of the XML of a message payload is:

    "mappings": {        "EndEvent_0ss2fp3": {            "inputs": {                "name": {                    "type": "variable",                    "value": "username"                },                "order-number": {                    "type": "value",                    "value": 1459283                }            }        }    },

An example of the XML of a message with a correlation key is:

<bpmn2:endEvent><bpmn2:incoming>SequenceFlow_8</bpmn2:incoming><bpmn2:messageEventDefinition messageRef="Message_1hxecs2" activiti:correlationKey="${userId}" />

In this example the message will only be caught if a catching event has amessageRef ofMessage_1hxecs2 and anactiviti:correlationKey that matches the value ofuserId.

An example of the XML of a message flow is:

<bpmn2:collaboration><bpmn2:participant processRef="Process_1d9yxsm" /><bpmn2:participant processRef="Process_1piiyp4" /><bpmn2:messageFlow sourceRef="Event_00acemq" targetRef="Event_13u5jtf" /></bpmn2:collaboration>

Basic properties

The basic properties for a signal intermediate catch event are:

Signal

A signal needs to be defined for the signal intermediate catch event to catch. A previously usedSignal can be selected from the dropdown in its properties, or a new one created using the+ symbol. ASignal name can then be set.

Signals can be restricted to the process instance they are thrown in, or be global in scope. The scope of a global signal is restricted to the project they are used in.

Signal events can be either catching or throwing. A throwing signal event will emit a signal when it is reached in a process instance that will be picked up by any catching signal event with a matching signal name. Signals can be restricted to the process instance they are thrown in, or be global in scope. The scope of a global signal is restricted to the project they are used in.

Theid of a signal will match against thesignalRef of a catching or throwing event.

Signal events are displayed as a triangle icon inside different shapes that differentiate between the event types. A solid triangle represents a throwing event, whilst a hollow triangle represents a catching event.

Signal intermediate catching events are displayed as two thin concentric circles with a hollow triangle icon inside.

An example of the XML of a signal intermediate catch events is:

<bpmn2:intermediateCatchEvent><bpmn2:incoming>SequenceFlow_5</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_6</bpmn2:outgoing>    <bpmn2:signalEventDefinition signalRef="Signal_0hnsd2r" /></bpmn2:intermediateCatchEvent>

An example of the XML of a signal with a global scope is:

<bpmn2:signal name="Signal_0hnsd2r" />

An example of the XML of a signal with a process instance scope is:

<bpmn2:signal name="Signal_0hnsd2r" activiti:scope="processInstance" />

Basic properties

The basic properties for a signal intermediate throw event are:

Signal

A signal needs to be defined for the signal intermediate throw event to emit when it is reached. A previously usedSignal can be selected from the dropdown in its properties, or a new one created using the+ symbol. ASignal name can then be set.

Signals can be restricted to the process instance they are thrown in, or be global in scope. The scope of a global signal is restricted to the project they are used in.

Signal events can be either catching or throwing. A throwing signal event will emit a signal when it is reached in a process instance that will be picked up by any catching signal event with a matching signal name. Signals can be restricted to the process instance they are thrown in, or be global in scope. The scope of a global signal is restricted to the project they are used in.

Theid of a signal will match against thesignalRef of a catching or throwing event.

Signal events are displayed as a triangle icon inside different shapes that differentiate between the event types. A solid triangle represents a throwing event, whilst a hollow triangle represents a catching event.

Signal intermediate throw events are displayed as two thin concentric circles with a solid triangle icon inside.

An example of the XML of a signal intermediate catch events is:

<bpmn2:intermediateThrowEvent><bpmn2:incoming>SequenceFlow_3</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_4</bpmn2:outgoing>   <bpmn2:signalEventDefinition signalRef="Signal_1jiw9tp" /></bpmn2:intermediateThrowEvent>

An example of the XML of a signal with a global scope is:

<bpmn2:signal name="Signal_0hnsd2r" />

An example of the XML of a signal with a process instance scope is:

<bpmn2:signal name="Signal_0hnsd2r" activiti:scope="processInstance" />

Basic properties

The basic properties for a timer intermediate catch event are:

Timer

A choice of timer must be set for timer start events, based on aCycle,Date orDuration.

Timer events are used to influence events at specific times, after a set amount of time has passed or at intervals. All timer events use the international standardISO 8601 for specifying time formats.

Note: All properties withintimerEventDefinition can accept process variables as their values as long as they are in ISO 8601 or cron expression format.

Timer events are displayed as a clock icon inside different shapes that differentiate between the event types.

timeDate

ThetimeDate property for timer events defines a specific date and time in ISO 8601 format for when the trigger will be fired and can include a specified time zone.

The following is an example of thetimerEventDefinition using atimeDate:

• 2017-05-17 represents the 17th May 2017 inYYYY-MM-DD format
• T12:42:23 represents the time of 12:42:23 inhh:mm:ss format
• Z represents that the time format is in UTC (Coordinated Universal Time). The time can also contain UTC offsets such as+01 for an hour ahead of UTC. When an offset is defined theZ is not required, for example:T12:42:23+01

timeDuration

ThetimeDuration property for timer events defines how long a timer should wait in ISO 8601 format before the trigger is fired.

The following are the letters used to refer to duration:

timeCycle

ThetimeCycle property for timer events defines intervals for the trigger to fire at. Intervals can be defined using the time intervals that adhere to the ISO 8601 standard or by using cron expressions.

Time intervals

Time intervals use the syntaxR/ to set a number of repetitions, for exampleR5/ would repeat five times.

Following the repetition, a duration can be set for when the repetition occurs, for exampleR5/PT10H would repeat every 10 hours, five times.

Note The duration uses the same format as fortimeDuration.

An optional end date can also be set after the duration and separated by a/.

Note: The end date uses the same format as fortimeDate.

Cron expression intervals

Cron expressions can also be used to define repeating triggers for timer events.

Timer intermediate catch events are displayed as two thin concentric circles with a clock icon inside.

An example of the XML of a signal intermediate catch events is:

<bpmn2:intermediateCatchEvent><bpmn2:incoming>SequenceFlow_3</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_4</bpmn2:outgoing><bpmn2:timerEventDefinition>  <bpmn2:timeDuration xsi:type="bpmn2:tFormalExpression">P5D</bpmn2:timeDuration></bpmn2:timerEventDefinition></bpmn2:intermediateCatchEvent>

Note: This will wait five days before continuing the process.

An example of the XML fortimeDate is:

<bpmn2:timerEventDefinition>   <bpmn2:timeDate xsi:type="bpmn2:tFormalExpression">2017-05-17T12:42:23Z</bpmn2:timeDate></bpmn2:timerEventDefinition>

An example of the XML fortimeDuration is:

<bpmn2:timerEventDefinition>  <bpmn2:timeDuration xsi:type="bpmn2:tFormalExpression">P5D</bpmn2:timeDuration></bpmn2:timerEventDefinition>

Note: This represents a duration of 5 days.

An example of the XML fortimeCycle using time interval syntax is:

<bpmn2:timerEventDefinition>  <bpmn2:timeCycle xsi:type="bpmn2:tFormalExpression">R3/PT30M</bpmn2:timeCycle></bpmn2:timerEventDefinition>

Note: This represents three repetitions every 30 minutes.

An example of the XML fortimeCycle using a cron expression is:

<bpmn2:timerEventDefinition>  <bpmn2:timeCycle>0 0/5 * * * ?</bpmn2:timeCycle></bpmn2:timerEventDefinition>

Note: This represents a trigger firing every 5 minutes beginning at the top of the hour.

Basic properties

The basic properties for an error boundary event are:

Error

An error needs to be defined for the error boundary event to catch. A previously createdError can be selected from the dropdown in its properties, or a new one created using the+ symbol. AnError name andError code can then be set.

Error events are used to model an exception in a business process. Errors are thrown by error end events and caught by error start events and error boundary events.

TheerrorRef property in theerrorEventDefinition of an error event element will match against theid of an error when viewing theXML Editor.

Error events are displayed as a lightning bolt icon inside different shapes that differentiate between the event types. A solid lightning bolt represents a throwing event, whilst a hollow lightning bolt represents a catching event.

To create a new error use the+ symbol against an error event such as a start error event, or make sure no BPMN element is selected by clicking on a blank section of the process canvas and theEdit Errors button will be visible in the right-hand properties panel.

Error boundary events are displayed as two thin concentric circles with a hollow lightning bolt icon inside attached to the border of another BPMN element.

An example of the XML of an error boundary events is:

<bpmn2:boundaryEvent attachedToRef="ServiceTask1"><bpmn2:errorEventDefinition errorRef="Error_0vbkbeb" /></bpmn2:boundaryEvent>

An example of the XML of a signal is:

<bpmn2:error name="payment-failed-error" errorCode="404" />

Basic properties

The basic properties for a message boundary event are:

Message

A message needs to be defined for the message boundary event to catch when it is thrown. A previously createdMessage can be selected from the dropdown in its properties, or a new one created using the+ symbol. AMessage name and payload can then be set.

Message

Messages have a name and contain a payload. They are sent by message throwing events and received by message catching events in a 1:1 relationship between throw events and catch events. Messages contain a payload known as a message payload and can be passed between scopes, for example between two different process definitions within the same diagram that are separated by differentpools.

The messageid property of a message is matched against themessageRef property in the corresponding throw and catch message elements when viewing theXML Editor.

To create a new message use the+ symbol against a message event such as a message boundary event, or make sure no BPMN element is selected by clicking on a blank section of the process canvas and theEdit Messages button will be visible in the right-hand properties panel.

Message events are displayed as an envelope icon inside different shapes that differentiate between the event types. A solid envelope represents a throwing event, whilst a hollow envelope represents a catching event.

Message payloads

Message payloads contain a set of values that are sent from a throwing event and received by a catching event.

Message payloads can only be created on a message throw event and contain one or more properties that have aname,type andvalue. The property types for payloads are:

The receiving message catch event is then used to map the received values in the payload to process variables in its own scope.

Message payload mappings can be viewed in theExtensions Editor of a process diagram. Throwing events are mapped asinputs and catching events are mapped asoutputs from an event.

Correlation keys

Message events can optionally contain a correlation key. If a correlation key is present then when a message is thrown it uses theactiviti:correlationKey value and themessageRef of the throwing event to match against the same two properties in a catching event. If only one property is matched then the message will not be caught.

Using aprocess variable for the correlation key in a throwing event and a static value for its corresponding catching event allows for the message to only be caught in specific circumstances.

Note: Message start events cannot contain a correlation key unless they are used in asub process.

Message flows

When messages are used between two differentpools the sequence flow that connects them is a dotted line called a message flow. The message flow is part of thecollaboration element in the XML created by introducing a pool. Message flows reference the throwing message event as thesourceRef and the catching message event as thetargetRef.

Message boundary events are displayed as two thin concentric circles, or two thin dashed concentric circles, with a hollow envelope icon inside attached to the border of another BPMN element.

An example of the XML of an interrupting message boundary events is:

<bpmn2:boundaryEvent attachedToRef="UserTask2"><bpmn2:outgoing>SequenceFlow5</bpmn2:outgoing><bpmn2:messageEventDefinition messageRef="Message_15xakkk" /></bpmn2:boundaryEvent>

An example of the XML of a non-interrupting message boundary events is:

<bpmn2:boundaryEvent cancelActivity="false" attachedToRef="SubProcess2"><bpmn2:outgoing>SequenceFlow8</bpmn2:outgoing><bpmn2:messageEventDefinition messageRef="Message_02satcd" /></bpmn2:boundaryEvent>

The XML representation of a message is:

<bpmn2:message name="Message_02satcd" />

An example of the XML of a message payload is:

    "mappings": {        "EndEvent_0ss2fp3": {            "inputs": {                "name": {                    "type": "variable",                    "value": "username"                },                "order-number": {                    "type": "value",                    "value": 1459283                }            }        }    },

An example of the XML of a message with a correlation key is:

<bpmn2:endEvent><bpmn2:incoming>SequenceFlow_8</bpmn2:incoming><bpmn2:messageEventDefinition messageRef="Message_1hxecs2" activiti:correlationKey="${userId}" />

In this example the message will only be caught if a catching event has amessageRef ofMessage_1hxecs2 and anactiviti:correlationKey that matches the value ofuserId.

An example of the XML of a message flow is:

<bpmn2:collaboration><bpmn2:participant processRef="Process_1d9yxsm" /><bpmn2:participant processRef="Process_1piiyp4" /><bpmn2:messageFlow sourceRef="Event_00acemq" targetRef="Event_13u5jtf" /></bpmn2:collaboration>

Basic properties

The basic properties for a signal boundary event are:

Signal

A signal needs to be defined for the signal boundary event to catch. A previously usedSignal can be selected from the dropdown in its properties, or a new one created using the+ symbol. ASignal name can then be set.

Signals can be restricted to the process instance they are thrown in, or be global in scope. The scope of a global signal is restricted to the project they are used in.

Signal events can be either catching or throwing. A throwing signal event will emit a signal when it is reached in a process instance that will be picked up by any catching signal event with a matching signal name. Signals can be restricted to the process instance they are thrown in, or be global in scope. The scope of a global signal is restricted to the project they are used in.

Theid of a signal will match against thesignalRef of a catching or throwing event.

Signal events are displayed as a triangle icon inside different shapes that differentiate between the event types. A solid triangle represents a throwing event, whilst a hollow triangle represents a catching event.

Signal boundary events are displayed as two thin concentric circles with a hollow triangle icon inside attached to the border of another BPMN element.

An example of the XML of a signal boundary events is:

<bpmn2:boundaryEvent attachedToRef="ServiceTask3">      <bpmn2:signalEventDefinition signalRef="Signal_0iikg75" /></bpmn2:boundaryEvent>

An example of the XML of a signal with a global scope is:

<bpmn2:signal name="Signal_0hnsd2r" />

An example of the XML of a signal with a process instance scope is:

<bpmn2:signal name="Signal_0hnsd2r" activiti:scope="processInstance" />

Basic properties

The basic properties for a timer boundary event are:

Timer

A choice of timer must be set for timer start events, based on aCycle,Date orDuration.

Timer events are used to influence events at specific times, after a set amount of time has passed or at intervals. All timer events use the international standardISO 8601 for specifying time formats.

Note: All properties withintimerEventDefinition can accept process variables as their values as long as they are in ISO 8601 or cron expression format.

Timer events are displayed as a clock icon inside different shapes that differentiate between the event types.

timeDate

ThetimeDate property for timer events defines a specific date and time in ISO 8601 format for when the trigger will be fired and can include a specified time zone.

The following is an example of thetimerEventDefinition using atimeDate:

• 2017-05-17 represents the 17th May 2017 inYYYY-MM-DD format
• T12:42:23 represents the time of 12:42:23 inhh:mm:ss format
• Z represents that the time format is in UTC (Coordinated Universal Time). The time can also contain UTC offsets such as+01 for an hour ahead of UTC. When an offset is defined theZ is not required, for example:T12:42:23+01

timeDuration

ThetimeDuration property for timer events defines how long a timer should wait in ISO 8601 format before the trigger is fired.

The following are the letters used to refer to duration:

timeCycle

ThetimeCycle property for timer events defines intervals for the trigger to fire at. Intervals can be defined using the time intervals that adhere to the ISO 8601 standard or by using cron expressions.

Time intervals

Time intervals use the syntaxR/ to set a number of repetitions, for exampleR5/ would repeat five times.

Following the repetition, a duration can be set for when the repetition occurs, for exampleR5/PT10H would repeat every 10 hours, five times.

Note The duration uses the same format as fortimeDuration.

An optional end date can also be set after the duration and separated by a/.

Note: The end date uses the same format as fortimeDate.

Cron expression intervals

Cron expressions can also be used to define repeating triggers for timer events.

Timer boundary events are displayed as two thin concentric circles, or two thin dashed concentric circles, with a clock icon inside attached to the border of another BPMN element.

An example of the XML of an interrupting timer boundary events is:

<bpmn2:boundaryEvent attachedToRef="UserTask1"><bpmn2:outgoing>SequenceFlow5</bpmn2:outgoing><bpmn2:timerEventDefinition><bpmn2:timeDuration xsi:type="bpmn2:tFormalExpression">PT10M</bpmn2:timeDuration></bpmn2:timerEventDefinition></bpmn2:boundaryEvent>

An example of the XML of a non-interrupting timer boundary events is:

<bpmn2:boundaryEvent cancelActivity="false" attachedToRef="SubProcess1"><bpmn2:outgoing>SequenceFlow8</bpmn2:outgoing><bpmn2:timerEventDefinition><bpmn2:timeDuration xsi:type="bpmn2:tFormalExpression">P5D</bpmn2:timeDuration></bpmn2:timerEventDefinition></bpmn2:boundaryEvent>

An example of the XML fortimeDate is:

<bpmn2:timerEventDefinition>   <bpmn2:timeDate xsi:type="bpmn2:tFormalExpression">2017-05-17T12:42:23Z</bpmn2:timeDate></bpmn2:timerEventDefinition>

An example of the XML fortimeDuration is:

<bpmn2:timerEventDefinition>  <bpmn2:timeDuration xsi:type="bpmn2:tFormalExpression">P5D</bpmn2:timeDuration></bpmn2:timerEventDefinition>

Note: This represents a duration of 5 days.

An example of the XML fortimeCycle using time interval syntax is:

<bpmn2:timerEventDefinition>  <bpmn2:timeCycle xsi:type="bpmn2:tFormalExpression">R3/PT30M</bpmn2:timeCycle></bpmn2:timerEventDefinition>

Note: This represents three repetitions every 30 minutes.

An example of the XML fortimeCycle using a cron expression is:

<bpmn2:timerEventDefinition>  <bpmn2:timeCycle>0 0/5 * * * ?</bpmn2:timeCycle></bpmn2:timerEventDefinition>

Note: This represents a trigger firing every 5 minutes beginning at the top of the hour.

Basic properties

The basic properties for an exclusive gateway are:

Default sequence flow

The name of asequence flow can be used to select a default flow for the gateway to take. This path will be followed if none of the other sequence flows evaluate to true. Conditional expressions can be configured on sequence flows to select which path is taken.

Exclusive gateways are displayed as a single thin diamond shape with an X icon inside.

Note: A single thin diamond on its own defaults to an exclusive gateway, however the BPMN specification does not allow diamonds with, and without, an X in the same process definition.

An example of the XML of an exclusive gateway is:

<bpmn2:exclusiveGateway name="Content Accepted?" default="SequenceFlow_2"><bpmn2:incoming>SequenceFlow_1</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_2</bpmn2:outgoing><bpmn2:outgoing>SequenceFlow_3</bpmn2:outgoing></bpmn2:exclusiveGateway>    <bpmn2:sequenceFlow sourceRef="Task_1" targetRef="ExclusiveGateway_1" />    <bpmn2:sequenceFlow name="yes" sourceRef="ExclusiveGateway_1" targetRef="Task_2"><bpmn2:conditionExpression xsi:type="bpmn:tFormalExpression">${content.approved == true}</bpmn2:conditionExpression></bpmn2:sequenceFlow>    <bpmn2:sequenceFlow name="no" sourceRef="ExclusiveGateway_1" targetRef="Task_3"><bpmn2:conditionExpression xsi:type="bpmn:tFormalExpression">${content.approved == false}</bpmn2:conditionExpression>    </bpmn2:sequenceFlow>

Basic properties

The basic properties for an inclusive gateway are:

Default sequence flow

The name of asequence flow can be used to select a default flow for the gateway to take. This path will be followed if none of the other sequence flows evaluate to true. Conditional expressions can be configured on sequence flows to select which path is taken.

Inclusive gateways are displayed as a single thin diamond shape with a circle inside.

An example of the XML of an inclusive gateway is:

<bpmn2:inclusiveGateway name="Content Metadata" default="SequenceFlow_2"><bpmn2:incoming>SequenceFlow_1</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_2</bpmn2:outgoing><bpmn2:outgoing>SequenceFlow_3</bpmn2:outgoing></bpmn2:inclusiveGateway>    <bpmn2:sequenceFlow sourceRef="Task_1" targetRef="InclusiveGateway_1" />    <bpmn2:sequenceFlow name="yes" sourceRef="InclusiveGateway_1" targetRef="Task_2"><bpmn2:conditionExpression xsi:type="bpmn:tFormalExpression">${content.size == "A4"}</bpmn2:conditionExpression></bpmn2:sequenceFlow>    <bpmn2:sequenceFlow name="no" sourceRef="InclusiveGateway_1" targetRef="Task_3"><bpmn2:conditionExpression xsi:type="bpmn:tFormalExpression">${content.origin == "Email"}</bpmn2:conditionExpression>    </bpmn2:sequenceFlow>

Basic properties

The basic properties for a parallel gateway are:

Parallel gateways are displayed as a single thin diamond shape with a + icon inside.

An example of the XML of a parallel gateway is:

<bpmn2:parallelGateway><bpmn2:sequenceFlow sourceRef="Fork_1" targetRef="UserTask_1" /> </bpmn2:sequenceFlow> <bpmn2:sequenceFlow sourceRef="Fork_1" targetRef="ServiceTask_1" /> </bpmn2:sequenceFlow></bpmn2:parallelGateway>

Basic properties

The basic properties for a business rule task are:

Multi-instance type

Business rule tasks can be set to repeat sequentially or in parallel when the process flow reaches them.

Decision table name

The name of thedecision table to use. The decision table must exist within the same project as the process definition to be selected. Select a decision table from the dropdown, else create a new one using the+ symbol.

Mapping type

The mapping type sets how data is passed between the decision table and the process. There arefive options for how to send this data. The default value isSend no variables.

Multi-instance allows for the element to be repeated within a process. There are two options for how to execute multi-instance elements: sequentially or in parallel.

• Sequential executions only ever have a single instance running at any one time. The next instance will only start after the previous one has been completed.

• Parallel executions start all instances at once, meaning they are all active and can all be worked on at the same time.

Multi instance elements are displayed as three parallel lines at the bottom of the original element. Sequential lines are horizontal and parallel lines are vertical.

Variables

Each multi-instance execution has three variables:

Note: These variables can be used in multi-instance expressions without having to be declared asprocess variables.

Each instance in the multi-instance execution also has an instance-local variable that is not visible to other instances, nor to the process instance:

Cardinality

Cardinality sets the number of instances to be executed by the multi-instance element. This can be set as a static value, aprocess variable or calculated as an expression.

Collection

A collection can be used to set the number of instances to be executed by referencing a list of items.

An element variable can optionally be used with a collection. An element variable is used to create a variable for each instance of the multi-instance element and each variable created by the element variable is assigned one value from the collection.

Completion condition

A completion condition can optionally be included for multi-instances. When the completion condition evaluates totrue, all remaining instances are cancelled and the multi-instance activity ends.

Results

A result collection can be set to aggregate the results from each instance into a variable. The result collection is created as a process variable after instance execution has finished.

The result element variable is used to select the field or variable from the BPMN element to aggregate into the result collection.

Business rule tasks are displayed as a single, thin rounded rectangle with a table icon inside.

An example of the XML of a business rule task is:

<bpmn2:serviceTask implementation="dmn-connector.EXECUTE_TABLE" />

An example of theExtensions Editor JSON of a process containing a business rule task is:

"constants": {"ServiceTask_2f85xew": {"_activiti_dmn_table_": {"value": "my-decision-table-1"            }        }    },

An example of the XML for an element that contains sequential multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics isSequential="true" />

An example of the XML for an element that contains parallel multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics  isSequential="false" />

or

<bpmn2:multiInstanceLoopCharacteristics />

An example of the XML of multi-instance cardinality is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>5</bpmn2:loopCardinality></bpmn2:multiInstanceLoopCharacteristics>

An example of the XML of a multi-instance collection is:

<bpmn2:userTask activiti:assignee="${user}"><bpmn2:incoming>SequenceFlow_5</bpmn2:incoming><bpmn2:multiInstanceLoopCharacteristics activiti:collection="${userList.users}" activiti:elementVariable="user"></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: Theactiviti:collection references a process variable calleduserList that contains the following JSON:

{"users":["user1", "user2", "user3"]}

In the example:

• Three user tasks will be created because there are three items in the process variable thatactiviti:collection uses.
• A variable will be created for each instance calledusers with the valuesuser1,user2 anduser3 because theactiviti:elementVariable is set to"users".
• A user tasks will be assigned to each of the users because theactiviti:assignee is set to{users} which is the name of the variable created in each instance by the element variable.

An example of the XML of a multi-instance completion condition is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>10</bpmn2:loopCardinality><bpmn2:completionCondition>${nrOfCompletedInstances/nrOfInstances >= 0.6 }</bpmn2:completionCondition></bpmn2:multiInstanceLoopCharacteristics>

Note: The completion condition will be met when 60% of instances have been completed and the remaining 4 instances will be cancelled.

An example of the XML of a multi-instance element is:

<bpmn2:userTask activiti:assignee="${users}"><bpmn2:multiInstanceLoopCharacteristics isSequential="true"><bpmn2:loopCardinality>4</bpmn2:loopCardinality><bpmn2:loopDataOutputRef>choices</bpmn2:loopDataOutputRef><bpmn2:outputDataItem name="flavor" /></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: The user task will run 4 times sequentially and the values offlavor from the form will be stored as a JSON object in the variablechoices. The process variablechoices will contain a list of results similar to the following:

["chocolate", "mint", "strawberry"]

Basic properties

The basic properties for a script task are:

Multi-instance type

Script tasks can be set to repeat sequentially or in parallel when the process flow reaches them.

Script name

The name of thescript to use. The script must exist within the same project as the process definition to be selected. Select a script from the dropdown, else create a new one using the+ symbol.

Mapping type

The mapping type sets how data is passed between the script and the process. There arefive options for how to send this data. The default value isSend no variables.

Multi-instance allows for the element to be repeated within a process. There are two options for how to execute multi-instance elements: sequentially or in parallel.

• Sequential executions only ever have a single instance running at any one time. The next instance will only start after the previous one has been completed.

• Parallel executions start all instances at once, meaning they are all active and can all be worked on at the same time.

Multi instance elements are displayed as three parallel lines at the bottom of the original element. Sequential lines are horizontal and parallel lines are vertical.

Variables

Each multi-instance execution has three variables:

Note: These variables can be used in multi-instance expressions without having to be declared asprocess variables.

Each instance in the multi-instance execution also has an instance-local variable that is not visible to other instances, nor to the process instance:

Cardinality

Cardinality sets the number of instances to be executed by the multi-instance element. This can be set as a static value, aprocess variable or calculated as an expression.

Collection

A collection can be used to set the number of instances to be executed by referencing a list of items.

An element variable can optionally be used with a collection. An element variable is used to create a variable for each instance of the multi-instance element and each variable created by the element variable is assigned one value from the collection.

Completion condition

A completion condition can optionally be included for multi-instances. When the completion condition evaluates totrue, all remaining instances are cancelled and the multi-instance activity ends.

Results

A result collection can be set to aggregate the results from each instance into a variable. The result collection is created as a process variable after instance execution has finished.

The result element variable is used to select the field or variable from the BPMN element to aggregate into the result collection.

Script tasks are displayed as a single thin, rounded rectangle with a script icon inside.

An example of the XML of a script task is:

<bpmn2:serviceTask name="Order script" implementation="script.EXECUTE"><bpmn2:documentation>A script to loop and update the list of orders.</bpmn2:documentation></bpmn2:serviceTask>

An example of theExtensions Editor JSON of a process containing a script task is:

    "constants": {        "Task_0ykbcv0": {            "_activiti_script_": {                "value": "order-script"            }        }    }

An example of the XML for an element that contains sequential multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics isSequential="true" />

An example of the XML for an element that contains parallel multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics  isSequential="false" />

or

<bpmn2:multiInstanceLoopCharacteristics />

An example of the XML of multi-instance cardinality is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>5</bpmn2:loopCardinality></bpmn2:multiInstanceLoopCharacteristics>

An example of the XML of a multi-instance collection is:

<bpmn2:userTask activiti:assignee="${user}"><bpmn2:incoming>SequenceFlow_5</bpmn2:incoming><bpmn2:multiInstanceLoopCharacteristics activiti:collection="${userList.users}" activiti:elementVariable="user"></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: Theactiviti:collection references a process variable calleduserList that contains the following JSON:

{"users":["user1", "user2", "user3"]}

In the example:

• Three user tasks will be created because there are three items in the process variable thatactiviti:collection uses.
• A variable will be created for each instance calledusers with the valuesuser1,user2 anduser3 because theactiviti:elementVariable is set to"users".
• A user tasks will be assigned to each of the users because theactiviti:assignee is set to{users} which is the name of the variable created in each instance by the element variable.

An example of the XML of a multi-instance completion condition is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>10</bpmn2:loopCardinality><bpmn2:completionCondition>${nrOfCompletedInstances/nrOfInstances >= 0.6 }</bpmn2:completionCondition></bpmn2:multiInstanceLoopCharacteristics>

Note: The completion condition will be met when 60% of instances have been completed and the remaining 4 instances will be cancelled.

An example of the XML of a multi-instance element is:

<bpmn2:userTask activiti:assignee="${users}"><bpmn2:multiInstanceLoopCharacteristics isSequential="true"><bpmn2:loopCardinality>4</bpmn2:loopCardinality><bpmn2:loopDataOutputRef>choices</bpmn2:loopDataOutputRef><bpmn2:outputDataItem name="flavor" /></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: The user task will run 4 times sequentially and the values offlavor from the form will be stored as a JSON object in the variablechoices. The process variablechoices will contain a list of results similar to the following:

["chocolate", "mint", "strawberry"]

Basic properties

The basic properties for a service task are:

Multi-instance type

Script tasks can be set to repeat sequentially or in parallel when the process flow reaches them.

Implementation

The implementation value is used to associate a connector with a service task. For business rule tasks and script tasks this value is set by default and cannot be changed. The format is<connector-name>.<connector-action>.

Action

An action selects which of the connector actions that service task should execute, for example whether to send a message or create a new channel in Slack when using theSlack connector.

Mapping type

The mapping type sets how data is passed between the connector and the process. There arefive options for how to send this data. The default value isSend no variables.

Multi-instance allows for the element to be repeated within a process. There are two options for how to execute multi-instance elements: sequentially or in parallel.

• Sequential executions only ever have a single instance running at any one time. The next instance will only start after the previous one has been completed.

• Parallel executions start all instances at once, meaning they are all active and can all be worked on at the same time.

Multi instance elements are displayed as three parallel lines at the bottom of the original element. Sequential lines are horizontal and parallel lines are vertical.

Variables

Each multi-instance execution has three variables:

Note: These variables can be used in multi-instance expressions without having to be declared asprocess variables.

Each instance in the multi-instance execution also has an instance-local variable that is not visible to other instances, nor to the process instance:

Cardinality

Cardinality sets the number of instances to be executed by the multi-instance element. This can be set as a static value, aprocess variable or calculated as an expression.

Collection

A collection can be used to set the number of instances to be executed by referencing a list of items.

An element variable can optionally be used with a collection. An element variable is used to create a variable for each instance of the multi-instance element and each variable created by the element variable is assigned one value from the collection.

Completion condition

A completion condition can optionally be included for multi-instances. When the completion condition evaluates totrue, all remaining instances are cancelled and the multi-instance activity ends.

Results

A result collection can be set to aggregate the results from each instance into a variable. The result collection is created as a process variable after instance execution has finished.

The result element variable is used to select the field or variable from the BPMN element to aggregate into the result collection.

Service tasks are displayed as a single, thin rounded rectangle with a cog icon inside.

An example of the XML of a service task is:

<bpmn2:serviceTask name="send-email" implementation="email-connector.SEND"><bpmn2:documentation>A connector that sends an email.</bpmn2:documentation><bpmn2:incoming>SequenceFlow_19fgs1w</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_64jaw7e</bpmn2:outgoing></bpmn2:serviceTask>

An example of the XML for an element that contains sequential multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics isSequential="true" />

An example of the XML for an element that contains parallel multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics  isSequential="false" />

or

<bpmn2:multiInstanceLoopCharacteristics />

An example of the XML of multi-instance cardinality is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>5</bpmn2:loopCardinality></bpmn2:multiInstanceLoopCharacteristics>

An example of the XML of a multi-instance collection is:

<bpmn2:userTask activiti:assignee="${user}"><bpmn2:incoming>SequenceFlow_5</bpmn2:incoming><bpmn2:multiInstanceLoopCharacteristics activiti:collection="${userList.users}" activiti:elementVariable="user"></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: Theactiviti:collection references a process variable calleduserList that contains the following JSON:

{"users":["user1", "user2", "user3"]}

In the example:

• Three user tasks will be created because there are three items in the process variable thatactiviti:collection uses.
• A variable will be created for each instance calledusers with the valuesuser1,user2 anduser3 because theactiviti:elementVariable is set to"users".
• A user tasks will be assigned to each of the users because theactiviti:assignee is set to{users} which is the name of the variable created in each instance by the element variable.

An example of the XML of a multi-instance completion condition is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>10</bpmn2:loopCardinality><bpmn2:completionCondition>${nrOfCompletedInstances/nrOfInstances >= 0.6 }</bpmn2:completionCondition></bpmn2:multiInstanceLoopCharacteristics>

Note: The completion condition will be met when 60% of instances have been completed and the remaining 4 instances will be cancelled.

An example of the XML of a multi-instance element is:

<bpmn2:userTask activiti:assignee="${users}"><bpmn2:multiInstanceLoopCharacteristics isSequential="true"><bpmn2:loopCardinality>4</bpmn2:loopCardinality><bpmn2:loopDataOutputRef>choices</bpmn2:loopDataOutputRef><bpmn2:outputDataItem name="flavor" /></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: The user task will run 4 times sequentially and the values offlavor from the form will be stored as a JSON object in the variablechoices. The process variablechoices will contain a list of results similar to the following:

["chocolate", "mint", "strawberry"]

Basic properties

The basic properties for a user task are:

Assignment

The users or groups that are able to complete a task. A single user can be assigned or candidates can be set. Candidates are a list of users or groups that may claim a task at runtime. A single user or candidates must be set for a user task.

A single assignee is set in the XML attributeactiviti:assignee and candidates in the attributeactiviti:candidateGroups. On theTask Assignment window use the dropdown menu on the top right to set if the assignment is for a single user or for candidates. If for candidates, from theAssignment type dropdown list, select eitherSequential orManual assignment types. Assigning a task manually means a user is assigned the task by another user or themselves. Assigning tasks sequentially means tasks are assigned automatically in a ‘round-robin’ scenario.

Users and groups can be set from three different sources:

• Static values are a free text field that has no validation as to whether a user exists or not. The text entered will require an exact match to ausername in the product environment for the user task to be correctly assigned at runtime.

• Identity allows forusers and groups to be searched for and selected for the assignment. The users and groups must exist whilst modeling to display in this list.

• Expression allows for an expression usingprocess variables to be used to select users and groups for the assignment. Expressions can be a simple process variable such as${userToAssign} or an expression such as${userDetails.username} that uses a process variable of type JSON. A JSON editor is provided for creating expressions for assignment, however the editor will only be displayed if there are process variables in the process.

  Note: The value"assignee": "${initiator}" can be set as an expression without creating a process variable. This will assign the task to the user that started the process instance.

The assignments for user tasks are stored in theassignments property of theExtensions Editor.

Note: Users and groups that are selected as assignees or candidates in a user task are automatically added asusers when deploying an application if they are set using the static or identity options. Setting an assignee or candidate using the expression source will require the potential users or groups to be manually assigned users when deploying an application.

Due date

An optional date and time for a user task to be completed by inISO 8601 format. There are three different ways of adding a due date:

• SelectUse static date then choose the time and date using the date picker.

• SelectUse time duration then enter a time in Months, Days, Hours, and Minutes.

• SelectUse process variable then choose a process variable from the dropdown list. This option uses a process variable that must use the typedatetime.

Checking theUse process variable box for due date allows aprocess variable to be used to generate the date. The process variable must be of typedatetime.

Multi-instance type

Script tasks can be set to repeat sequentially or in parallel when the process flow reaches them.

Priority

An optional priority for the user task between 0 and 4. The priority property is to aid end users in their task management.

Form name

Aform can be assigned to the user task. The form must exist within the same project as the process definition to be selected. Select a form from the dropdown, else create a new form using the+ symbol.

Once a form has been selected, it can be edited using theOpen Form symbol.

Mapping type

The mapping type sets how data is passed between the user task and the process. There arefive options for how to send this data. The default value isSend no variables.

Multi-instance allows for the element to be repeated within a process. There are two options for how to execute multi-instance elements: sequentially or in parallel.

• Sequential executions only ever have a single instance running at any one time. The next instance will only start after the previous one has been completed.

• Parallel executions start all instances at once, meaning they are all active and can all be worked on at the same time.

Multi instance elements are displayed as three parallel lines at the bottom of the original element. Sequential lines are horizontal and parallel lines are vertical.

Variables

Each multi-instance execution has three variables:

Note: These variables can be used in multi-instance expressions without having to be declared asprocess variables.

Each instance in the multi-instance execution also has an instance-local variable that is not visible to other instances, nor to the process instance:

Cardinality

Cardinality sets the number of instances to be executed by the multi-instance element. This can be set as a static value, aprocess variable or calculated as an expression.

Collection

A collection can be used to set the number of instances to be executed by referencing a list of items.

An element variable can optionally be used with a collection. An element variable is used to create a variable for each instance of the multi-instance element and each variable created by the element variable is assigned one value from the collection.

Completion condition

A completion condition can optionally be included for multi-instances. When the completion condition evaluates totrue, all remaining instances are cancelled and the multi-instance activity ends.

Results

A result collection can be set to aggregate the results from each instance into a variable. The result collection is created as a process variable after instance execution has finished.

The result element variable is used to select the field or variable from the BPMN element to aggregate into the result collection.

User tasks are displayed as a single thin, rounded rectangle with a user icon inside.

An example of the XML of a user task is:

<bpmn2:userTask name="Order" activiti:formKey="form-38098a3e-bff1-46cb-ba0f-0c94fdb287ed" activiti:assignee="${userDetails.username}" activiti:dueDate="2020-01-01T01:00:00" activiti:priority="2"><bpmn2:documentation>A form to choose the flavor of ice cream.</bpmn2:documentation><bpmn2:incoming>SequenceFlow_02eaofe</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_14ma5mo</bpmn2:outgoing></bpmn2:userTask>

An example of the XML for an element that contains sequential multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics isSequential="true" />

An example of the XML for an element that contains parallel multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics  isSequential="false" />

or

<bpmn2:multiInstanceLoopCharacteristics />

An example of the XML of multi-instance cardinality is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>5</bpmn2:loopCardinality></bpmn2:multiInstanceLoopCharacteristics>

An example of the XML of a multi-instance collection is:

<bpmn2:userTask activiti:assignee="${user}"><bpmn2:incoming>SequenceFlow_5</bpmn2:incoming><bpmn2:multiInstanceLoopCharacteristics activiti:collection="${userList.users}" activiti:elementVariable="user"></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: Theactiviti:collection references a process variable calleduserList that contains the following JSON:

{"users":["user1", "user2", "user3"]}

In the example:

• Three user tasks will be created because there are three items in the process variable thatactiviti:collection uses.
• A variable will be created for each instance calledusers with the valuesuser1,user2 anduser3 because theactiviti:elementVariable is set to"users".
• A user tasks will be assigned to each of the users because theactiviti:assignee is set to{users} which is the name of the variable created in each instance by the element variable.

An example of the XML of a multi-instance completion condition is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>10</bpmn2:loopCardinality><bpmn2:completionCondition>${nrOfCompletedInstances/nrOfInstances >= 0.6 }</bpmn2:completionCondition></bpmn2:multiInstanceLoopCharacteristics>

Note: The completion condition will be met when 60% of instances have been completed and the remaining 4 instances will be cancelled.

An example of the XML of a multi-instance element is:

<bpmn2:userTask activiti:assignee="${users}"><bpmn2:multiInstanceLoopCharacteristics isSequential="true"><bpmn2:loopCardinality>4</bpmn2:loopCardinality><bpmn2:loopDataOutputRef>choices</bpmn2:loopDataOutputRef><bpmn2:outputDataItem name="flavor" /></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: The user task will run 4 times sequentially and the values offlavor from the form will be stored as a JSON object in the variablechoices. The process variablechoices will contain a list of results similar to the following:

["chocolate", "mint", "strawberry"]

Basic properties

The basic properties for a call activity are:

Multi-instance type

Sub-processes can be set to repeat sequentially or in parallel when the process flow reaches them.

Called element

The process definition the call activity should start is set using the called element property.

The called element can be set in two ways:

• Static values select a process definition name from a dropdown list.

• Expression values allow an expression to be set to dynamically call a process definition based on an expression or process variable.

Mapping type

The mapping type sets how data is passed between the parent process and the process being started by the call activity. There arefive options for how to send this data. The default value isSend no variables.

Note: if anExpression is used to set which process definition to call in the call element property, it is not possible to explicitly map the variable exchange in the mapping type.

Multi-instance allows for the element to be repeated within a process. There are two options for how to execute multi-instance elements: sequentially or in parallel.

• Sequential executions only ever have a single instance running at any one time. The next instance will only start after the previous one has been completed.

• Parallel executions start all instances at once, meaning they are all active and can all be worked on at the same time.

Multi instance elements are displayed as three parallel lines at the bottom of the original element. Sequential lines are horizontal and parallel lines are vertical.

Variables

Each multi-instance execution has three variables:

Note: These variables can be used in multi-instance expressions without having to be declared asprocess variables.

Each instance in the multi-instance execution also has an instance-local variable that is not visible to other instances, nor to the process instance:

Cardinality

Cardinality sets the number of instances to be executed by the multi-instance element. This can be set as a static value, aprocess variable or calculated as an expression.

Collection

A collection can be used to set the number of instances to be executed by referencing a list of items.

An element variable can optionally be used with a collection. An element variable is used to create a variable for each instance of the multi-instance element and each variable created by the element variable is assigned one value from the collection.

Completion condition

A completion condition can optionally be included for multi-instances. When the completion condition evaluates totrue, all remaining instances are cancelled and the multi-instance activity ends.

Results

A result collection can be set to aggregate the results from each instance into a variable. The result collection is created as a process variable after instance execution has finished.

The result element variable is used to select the field or variable from the BPMN element to aggregate into the result collection.

Call activities are displayed as a single, thick rounded rectangle without an icon inside.

An example of the XML of a call activity is:

<bpmn2:callActivity name="Start request process" calledElement="process-a6d6ca00-cbb6-45d6-ae24-50ef53d37cc4"><bpmn2:incoming>SequenceFlow_8</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_9</bpmn2:outgoing></bpmn2:callActivity>

An example of the XML for an element that contains sequential multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics isSequential="true" />

An example of the XML for an element that contains parallel multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics  isSequential="false" />

or

<bpmn2:multiInstanceLoopCharacteristics />

An example of the XML of multi-instance cardinality is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>5</bpmn2:loopCardinality></bpmn2:multiInstanceLoopCharacteristics>

An example of the XML of a multi-instance collection is:

<bpmn2:userTask activiti:assignee="${user}"><bpmn2:incoming>SequenceFlow_5</bpmn2:incoming><bpmn2:multiInstanceLoopCharacteristics activiti:collection="${userList.users}" activiti:elementVariable="user"></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: Theactiviti:collection references a process variable calleduserList that contains the following JSON:

{"users":["user1", "user2", "user3"]}

In the example:

• Three user tasks will be created because there are three items in the process variable thatactiviti:collection uses.
• A variable will be created for each instance calledusers with the valuesuser1,user2 anduser3 because theactiviti:elementVariable is set to"users".
• A user tasks will be assigned to each of the users because theactiviti:assignee is set to{users} which is the name of the variable created in each instance by the element variable.

An example of the XML of a multi-instance completion condition is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>10</bpmn2:loopCardinality><bpmn2:completionCondition>${nrOfCompletedInstances/nrOfInstances >= 0.6 }</bpmn2:completionCondition></bpmn2:multiInstanceLoopCharacteristics>

Note: The completion condition will be met when 60% of instances have been completed and the remaining 4 instances will be cancelled.

An example of the XML of a multi-instance element is:

<bpmn2:userTask activiti:assignee="${users}"><bpmn2:multiInstanceLoopCharacteristics isSequential="true"><bpmn2:loopCardinality>4</bpmn2:loopCardinality><bpmn2:loopDataOutputRef>choices</bpmn2:loopDataOutputRef><bpmn2:outputDataItem name="flavor" /></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: The user task will run 4 times sequentially and the values offlavor from the form will be stored as a JSON object in the variablechoices. The process variablechoices will contain a list of results similar to the following:

["chocolate", "mint", "strawberry"]

Basic properties

The basic properties for a sub-process are:

Multi-instance type

Sub-processes can be set to repeat sequentially or in parallel when the process flow reaches them.

Multi-instance allows for the element to be repeated within a process. There are two options for how to execute multi-instance elements: sequentially or in parallel.

• Sequential executions only ever have a single instance running at any one time. The next instance will only start after the previous one has been completed.

• Parallel executions start all instances at once, meaning they are all active and can all be worked on at the same time.

Multi instance elements are displayed as three parallel lines at the bottom of the original element. Sequential lines are horizontal and parallel lines are vertical.

Variables

Each multi-instance execution has three variables:

Note: These variables can be used in multi-instance expressions without having to be declared asprocess variables.

Each instance in the multi-instance execution also has an instance-local variable that is not visible to other instances, nor to the process instance:

Cardinality

Cardinality sets the number of instances to be executed by the multi-instance element. This can be set as a static value, aprocess variable or calculated as an expression.

Collection

A collection can be used to set the number of instances to be executed by referencing a list of items.

An element variable can optionally be used with a collection. An element variable is used to create a variable for each instance of the multi-instance element and each variable created by the element variable is assigned one value from the collection.

Completion condition

A completion condition can optionally be included for multi-instances. When the completion condition evaluates totrue, all remaining instances are cancelled and the multi-instance activity ends.

Results

A result collection can be set to aggregate the results from each instance into a variable. The result collection is created as a process variable after instance execution has finished.

The result element variable is used to select the field or variable from the BPMN element to aggregate into the result collection.

Whilst expanded, sub-processes are displayed as a single, thin rounded rectangle with the other BPMN elements they contain visible.

Whilst collapsed, sub-processes are displayed as a single, thin rounded rectangle with a+ symbol. The BPMN elements they contain are not visible in this state.

An example of the XML of a sub-process is:

<bpmn2:subProcess><bpmn2:incoming>SequenceFlow_8</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_9</bpmn2:outgoing>...</bpmn2:subProcess>

An example of the XML for an element that contains sequential multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics isSequential="true" />

An example of the XML for an element that contains parallel multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics  isSequential="false" />

or

<bpmn2:multiInstanceLoopCharacteristics />

An example of the XML of multi-instance cardinality is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>5</bpmn2:loopCardinality></bpmn2:multiInstanceLoopCharacteristics>

An example of the XML of a multi-instance collection is:

<bpmn2:userTask activiti:assignee="${user}"><bpmn2:incoming>SequenceFlow_5</bpmn2:incoming><bpmn2:multiInstanceLoopCharacteristics activiti:collection="${userList.users}" activiti:elementVariable="user"></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: Theactiviti:collection references a process variable calleduserList that contains the following JSON:

{"users":["user1", "user2", "user3"]}

In the example:

• Three user tasks will be created because there are three items in the process variable thatactiviti:collection uses.
• A variable will be created for each instance calledusers with the valuesuser1,user2 anduser3 because theactiviti:elementVariable is set to"users".
• A user tasks will be assigned to each of the users because theactiviti:assignee is set to{users} which is the name of the variable created in each instance by the element variable.

An example of the XML of a multi-instance completion condition is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>10</bpmn2:loopCardinality><bpmn2:completionCondition>${nrOfCompletedInstances/nrOfInstances >= 0.6 }</bpmn2:completionCondition></bpmn2:multiInstanceLoopCharacteristics>

Note: The completion condition will be met when 60% of instances have been completed and the remaining 4 instances will be cancelled.

An example of the XML of a multi-instance element is:

<bpmn2:userTask activiti:assignee="${users}"><bpmn2:multiInstanceLoopCharacteristics isSequential="true"><bpmn2:loopCardinality>4</bpmn2:loopCardinality><bpmn2:loopDataOutputRef>choices</bpmn2:loopDataOutputRef><bpmn2:outputDataItem name="flavor" /></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: The user task will run 4 times sequentially and the values offlavor from the form will be stored as a JSON object in the variablechoices. The process variablechoices will contain a list of results similar to the following:

["chocolate", "mint", "strawberry"]

Basic properties

The basic properties for an event sub-process are:

Multi-instance type

Sub-processes can be set to repeat sequentially or in parallel when the process flow reaches them.

Multi-instance allows for the element to be repeated within a process. There are two options for how to execute multi-instance elements: sequentially or in parallel.

• Sequential executions only ever have a single instance running at any one time. The next instance will only start after the previous one has been completed.

• Parallel executions start all instances at once, meaning they are all active and can all be worked on at the same time.

Multi instance elements are displayed as three parallel lines at the bottom of the original element. Sequential lines are horizontal and parallel lines are vertical.

Variables

Each multi-instance execution has three variables:

Note: These variables can be used in multi-instance expressions without having to be declared asprocess variables.

Each instance in the multi-instance execution also has an instance-local variable that is not visible to other instances, nor to the process instance:

Cardinality

Cardinality sets the number of instances to be executed by the multi-instance element. This can be set as a static value, aprocess variable or calculated as an expression.

Collection

A collection can be used to set the number of instances to be executed by referencing a list of items.

An element variable can optionally be used with a collection. An element variable is used to create a variable for each instance of the multi-instance element and each variable created by the element variable is assigned one value from the collection.

Completion condition

A completion condition can optionally be included for multi-instances. When the completion condition evaluates totrue, all remaining instances are cancelled and the multi-instance activity ends.

Results

A result collection can be set to aggregate the results from each instance into a variable. The result collection is created as a process variable after instance execution has finished.

The result element variable is used to select the field or variable from the BPMN element to aggregate into the result collection.

Event sub-processes are displayed as a single, thin dotted rectangle.

An example of the XML of an event sub-process is:

<bpmn2:subProcess triggeredByEvent="true">...</bpmn2:subProcess>

An example of the XML for an element that contains sequential multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics isSequential="true" />

An example of the XML for an element that contains parallel multi-instance elements is:

<bpmn2:multiInstanceLoopCharacteristics  isSequential="false" />

or

<bpmn2:multiInstanceLoopCharacteristics />

An example of the XML of multi-instance cardinality is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>5</bpmn2:loopCardinality></bpmn2:multiInstanceLoopCharacteristics>

An example of the XML of a multi-instance collection is:

<bpmn2:userTask activiti:assignee="${user}"><bpmn2:incoming>SequenceFlow_5</bpmn2:incoming><bpmn2:multiInstanceLoopCharacteristics activiti:collection="${userList.users}" activiti:elementVariable="user"></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: Theactiviti:collection references a process variable calleduserList that contains the following JSON:

{"users":["user1", "user2", "user3"]}

In the example:

• Three user tasks will be created because there are three items in the process variable thatactiviti:collection uses.
• A variable will be created for each instance calledusers with the valuesuser1,user2 anduser3 because theactiviti:elementVariable is set to"users".
• A user tasks will be assigned to each of the users because theactiviti:assignee is set to{users} which is the name of the variable created in each instance by the element variable.

An example of the XML of a multi-instance completion condition is:

<bpmn2:multiInstanceLoopCharacteristics><bpmn2:loopCardinality>10</bpmn2:loopCardinality><bpmn2:completionCondition>${nrOfCompletedInstances/nrOfInstances >= 0.6 }</bpmn2:completionCondition></bpmn2:multiInstanceLoopCharacteristics>

Note: The completion condition will be met when 60% of instances have been completed and the remaining 4 instances will be cancelled.

An example of the XML of a multi-instance element is:

<bpmn2:userTask activiti:assignee="${users}"><bpmn2:multiInstanceLoopCharacteristics isSequential="true"><bpmn2:loopCardinality>4</bpmn2:loopCardinality><bpmn2:loopDataOutputRef>choices</bpmn2:loopDataOutputRef><bpmn2:outputDataItem name="flavor" /></bpmn2:multiInstanceLoopCharacteristics></bpmn2:userTask>

Note: The user task will run 4 times sequentially and the values offlavor from the form will be stored as a JSON object in the variablechoices. The process variablechoices will contain a list of results similar to the following:

["chocolate", "mint", "strawberry"]

Basic properties

The basic properties for a sequence flow are:

Condition expression

A condition expression can be set when a sequence flow is connected to an inclusive or exclusive gateway. Conditions will be evaluated to decide whether a path is taken or not. The expression syntax can reference process variables using expressions such as${content.approved} == false} where that path will be taken if theapproved attribute of the variablecontent is set tofalse.

Another example of conditional expressions when evaluating a sequence flow is using amounts, for example${amount>500} will take the sequence flow if the process variableamount is greater than 500 at the point the gateway is reached.

Sequence flows are displayed as single black lines with an arrow indicating the direction of flow.

An example of the XML of a sequence flow is:

<bpmn2:incoming>SequenceFlow_1</bpmn2:incoming><bpmn2:outgoing>SequenceFlow_2</bpmn2:outgoing>

An example of the XML of a sequence flow with a condition expression set is:

<bpmn2:sequenceFlow name="no" sourceRef="ExclusiveGateway_1" targetRef="Task_1"><bpmn2conditionExpression xsi:type="bpmn:tFormalExpression">${content.approved == false}</bpmn2:conditionExpression></bpmn2:sequenceFlow>

Basic properties

The basic properties for a pool are:

Note: Pools use the process definition name rather than having an additional name property.

Basic properties

The basic properties for a lane are:

An example of the XML of a pool is:

<bpmn2:collaboration><bpmn2:participant processRef="Process_1d9yxsm" /><bpmn2:participant processRef="Process_1piiyp4" /></bpmn2:collaboration>

An example of the XML of a lane is:

<bpmn2:process><bpmn2:laneSet><bpmn2:lane name="HR Department"><bpmn2:flowNodeRef>Event_0b61hqt</bpmn2:flowNodeRef><bpmn2:flowNodeRef>Gateway_1dmrhcn</bpmn2:flowNodeRef></bpmn2:lane><bpmn2:lane name="Finance Department"><bpmn2:flowNodeRef>Task_16ju082</bpmn2:flowNodeRef><bpmn2:flowNodeRef>Event_00acemq</bpmn2:flowNodeRef></bpmn2:lane></bpmn2:laneSet>