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 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.

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 Worfklow 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 specify the list report that returns records for initiating processes and scheduling in crontab notation.

Can be used to start an event sub-process.

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 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.

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.

Escalation Start Event

Can only be used 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.

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 Worfklow tool. See here. Note that BPM tool intruduces additonal 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 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.

Signal Intermediate Event (Throwing)

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.

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.

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.

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 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.

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.

Note: If an 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). Available 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 coditions 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).