Events are displayed on a flowchart as circles.
- Start Events
- Intermediate Events
- End Events
- Boundary Events
Doesn't have parameters. It's a starting point of the process. Start Event can be initiated manually by a user who has an access to create processes. The user needs to click 'Start Process' button on the list view of processes.
Can be used as an entry point of a sub-process.
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 Worfklow tool. See here.
Can be used to start an event sub-process.
A starting point of the process. It initiates processes by scheduling. You need to specify the list report that returns records for initiating processes and scheduling in crontab notation.
Can be used to start an event sub-process.
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 target's id.
!!! 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.
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.
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.
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 actvity, 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.
This event stops the flow until specified criteria is met. Conditions are defined in the same way as in Worfklow tool. See here. Note that BPM tool intruduces additonal functions that can be used in formula.
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 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.
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.
Broadcasts a specified signal. Placeholders can be used in a signal name. Example: test.{$id}, {$id} will be replaced with target's id.
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.
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).
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.
As of v2.14.
Behaves the same as the compensation end event with the only difference that it continues flow exection to the next element.
Can be useful to process compensations in a specific order.
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.
Ends all flows. Process is subsequently ended.
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.
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.
Ends the flow and broadcasts a specified signal.
Placeholders can be used in a signal name. Example: test.{$id}, {$id} will be replaced with target's id.
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.
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 activites 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 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.
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.
Triggered when specific conditions are met. Note that non interrupting event can be triggered multiple times, when coditions get met, then get not met, and met again.
Triggered after a specific period of time. The timer starts once the activity starts.
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.
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.
Triggered once an email is received. It functions the same as Message Intermediate Event (Catching).
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 successfuly 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.