BPM Events¶
Events represent something that happens during a business process. They also start, end and interrupt the process flow. Depicted as a circle.
Events can be divided into the following groups:
- Start – green circle. They are entry points of processes and sub-processes.
- Intermediate – blue circle. Occur between start and end events in a process. Can throw or catch.
- End – red circle. Define final points of process flows.
- Boundary – blue circle attached to an activity. They allow to interact with running activities. Technically, there are intermediate catching events.
All available events:
- Start Events
- Intermediate Events
- End Events
- Boundary Events
Start Events¶
Start Event¶
Doesn't have parameters. It's a starting point of the process. Start Event can be initiated manually by a user who has access to create processes. This can be done either from the processes list view or from the detail view of a target record.
Can be also used as an entry point of a sub-process.
Conditional Start Event¶
A starting point of the process. It's supposed to be triggered automatically when specified conditions are met. There are three types of triggers: 'After record created', 'After record updated', 'After record saved'. Conditions are defined in the same way as in the Workflows tool. See here.
Can be used to start an event sub-process.
Timer Start Event¶
A starting point of the process. It initiates processes by scheduling. You need to select a list report (which returns records for initiating processes) and specify execution scheduling (in crontab notation).
Can be also used to start an event sub-process. In this case, it is scheduled to be triggered at a time defined by event parameters.
Signal Start Event¶
Can be used to start processes and event sub-processes.
When it is used to start a process, only object signals can be used.
When it is used to start an event sub-process, it's possible to use placeholders in a signal name. Example: test.{$id}, {$id} will be replaced with the ID of the target record.
Note
Signals are not limited by a process scope. Signal triggered in one BPM process can be caught in another process.
Note
Signal name cannot be empty.
See more info about signals.
Error Start Event¶
Can only be used to start an event sub-process. It's triggered once an error event is thrown within the same process.
If Error Code is specified, it will be triggered only when an error with the same code occurs. If Error Code is empty, it will catch any error.
It can't be non interrupting, because a process gets terminated once an error event is thrown.
It's possible to view an error code and message in the flow log (as of v2.14).
The error code and the exception message can be obtained further in the flow with formula functions bpm\caughtErrorCode and bpm\caughtErrorMessage (as of v2.14).
Note
When an error event sub-process is defined inside a regular sub-process, it may be reasonable to re-throw the error in the end of the event sub-process with the Error End Event. It will propagate the error to the top level.
Escalation Start Event¶
Can be used only to start an event sub-process. It's triggered once an escalation event it thrown within the same process.
If Escalation Code is specified, it will be triggered only when an escalation with the same code occurs. If Escalation Code is empty, it will catch any escalation.
Compensation Start Event¶
As of v2.14.
Starts a sub-process compensation handler. Can be used only in an event sub-process.
When the parent process initiates compensation for the sub-process activity, if there's no boundary compensation event attached to that activity, it will check whether the sub-process contains an event sub-process with a compensation start event (called Compensation Handler). Then it executes the compensation handler. The compensation handler usually is supposed to explicitly throw compensation events to compensate activities of the sub-process.
Note
Actual only when the event sub-process is inside a regular sub-process.
In case of a multi-instance sub-process, the compensation handler is processed for each completed instance of the sub-process.
Intermediate Events¶
Conditional Intermediate Event (Catching)¶
This event stops the flow until specified criteria is met. Conditions are defined in the same way as in the Workflow tool. See here. Note that BPM tool introduces additional functions that can be used in formula.
Timer Intermediate Event (Catching)¶
This event stops the flow and waits as long as it is specified by the event's parameters.
For more complex timer settings you can utilize formula. Formula scripts should return a Date-Time value (in UTC timezone). Once this time comes, the flow will be proceeded to the next element.
By utilizing datetime\closest formula function it's possible to set the timer to a specific time in the future, e.g. the beginning of the next working day.
Signal Intermediate Event (Catching)¶
Stops the flow until a specific signal catched. Placeholders can be used in a signal name.
Note
Signal name can not be empty.
See more info about signals.
Signal Intermediate Event (Throwing)¶
Broadcasts a specified signal. Placeholders can be used in a signal name. Example: test.{$id}, {$id} will be replaced with the ID of the target record.
If the first character of the signal name is @, it will broadcast an object signal along with the current target record. This signal type can be used only to initiate a new process or trigger a workflow rule.
Note
Signals are not limited by a process scope. Signal triggered in one BPM process can be caught in another process.
Note
Signal name can not be empty.
See more info about signals.
Message Intermediate Event (Catching)¶
Stops the flow until an email is received.
Only emails sent not by internal users can trigger the event.
It's possible to utilize the event in pair with Send Message task. The event will wait until the sent email is replied. Specify that email in Replied To parameter.
Related To parameter requires that email was related (via Parent field) to a specific record.
There is the ability to specify formula conditions that the email should satisfy to trigger the event. You can utilize it to skip auto-response emails or to catch emails containing a specific ID. Formula example: string\contains(body, $id).
Escalation Intermediate Event (Throwing)¶
Throws an escalation. Escalation Code can be specified. Escalation can be catched by a boundary event (if it's thrown within a sub-process) or by event sub-process.
Compensation Intermediate Event (Throwing)¶
As of v2.14.
Behaves the same as the compensation end event with the only difference that it continues flow execution to the next element.
Can be useful to process compensations in a specific order.
End Events¶
End Event¶
Ends the current flow. It doesn't end flows running in parallel. When the flow reaches the end event and there isn't anything running in parallel, then process ends.
Terminate End Event¶
Ends all flows. Process is subsequently ended.
Error End Event¶
Terminates the process and triggers an error. Error Code can be specified. Error can be catched by a boundary event (if it's thrown within a sub-process) or by event sub-process.
Note
Uncaught errors are propagated to the parent process. As of v2.14.
Escalation End Event¶
Ends the flow and triggers an escalation. Escalation Code can be specified. Escalation can be catched by a boundary event (if it's thrown within a sub-process) or by event sub-process.
Signal End Event¶
Ends the flow and broadcasts a specified signal.
Placeholders can be used in a signal name. Example: test.{$id}, {$id} will be replaced with the ID of the target record.
If the first character of the signal name is @, it will broadcast an object signal along with the current target record. This signal type can be used only to initiate a new process or trigger a workflow rule.
Note
Signals are not limited by a process scope. Signal triggered in one BPM process can be caught in another process.
Note
Signal name can not be empty.
See more info about signals.
Compensation End Event¶
As of v2.14.
Initiates compensation and ends the flow once compensation is completed.
Can compensate a specific activity (by specifying an activity's ID, the activity ID can be obtained on the detail view of the activity) or all activities (that are visible from the event). Only completed activities (not failed or interrupted) are compensated.
An activity is considered visible from the throwing Event when:
- It is contained in normal flow at the same level of the process/sub-process.
- It is contained in the parent process/sub-process of an event sub-process in which the Event is contained.
In the same level:
From the event sub-process:
When the activity ID is omitted, all visible completed activities are compensated in the order reverse to their instantiation.
Compensation is supposed to perform undo actions when something went wrong. Usually, compensation is triggered from error handlers.
Boundary Events¶
Boundary events can be attached to activities (usually sub-processes). Boundary event can interrupt an activity (if param Is Interrupting is checked). Non interrupting boundary event can be triggered multiple times.
Error Intermediate Event (Boundary)¶
It's triggered once an error event is thrown withing the activity (sub-process) it's attached to.
It can't be non interrupting, because the activity gets terminated once an error event is thrown.
If Error Code is specified, it will be triggered only when an error with the same code occurs. If Error Code is empty, it will catch any error.
It's possible to view an error code and message in the flow log (as of v2.14).
The error code and the exception message can be obtained further in the flow with formula functions bpm\caughtErrorCode and bpm\caughtErrorMessage (as of v2.14).
Note
If the error event is attached to a task with the Send HTTP Request action, it's possible to catch a specific response error code (e.g. 404, 403). As of v2.8.6.
Conditional Intermediate Event (Boundary)¶
Triggered when specific conditions are met. Note that non interrupting event can be triggered multiple times, when conditions get met, then get not met, and met again.
Timer Intermediate Event (Boundary)¶
Triggered after a specific period of time. The timer starts once the activity starts.
Escalation Intermediate Event (Boundary)¶
It's triggered once an escalation event is thrown within the activity (sub-process) it's attached to.
If Escalation Code is specified, it will be triggered only when an escalation with the same code occurs. If Escalation Code is empty, it will catch any escalation.
Signal Intermediate Event (Boundary)¶
It's triggered once a specific signal is broadcasted. Note that a signal can be triggered from anywhere in the system, not necessarily in the same process.
Placeholders can be used in a signal name. E.g. test.{$id}, {$id} will be replaced with the target's ID.
Message Intermediate Event (Boundary)¶
Triggered once an email is received. It functions the same as Message Intermediate Event (Catching).
Compensation Intermediate Event (Boundary)¶
As of v2.14.
Triggered once compensation is initiated for an activity it is attached to. Must be connected with a compensation activity (task or sub-process).
Note
Compensation can be applied only for activities that were successfully completed.
When it's a sub-process being compensated, the compensation activity does not have access to the sub-process internal state (called Black-Box compensation). To be able to access the internal state, use the compensation event sub-process inside the sub-process instead.
In case of a multi-instance sub-process, the compensation activity is processed for each completed instance of the sub-process.