An event is something that “happens” during the course of a process. These events affect the flow of the process and usually have a cause or impact.
Starting or ending a process, receiving a message from another process, sending a document … all can be considered Events.
Events have a circle shape with differences in their outlines and inner symbols depending on their type and timing.
The start event identifies the starting point of a process, although it’s not mandatory in the documentation it’s good to use it to avoid misunderstandings and ensure good practices.
Start (generic / manual)
A Normal Start represents the manual start of the process by a user
It represents an automatic start by a temporal cyclical pattern: daily, monthly, annual, etc.
The process is started from a message, which can be an email, web service or any available connector on the platform.
It’s triggered when a condition becomes true. It can be used, for example, to generate a process instance when a new record is inserted into a custom register.
This initiator is triggered whenever it receives a signal coming from a process-initiated broadcast.
It represents a process start based on several possible rules, but requiring only one to trigger the process.
This initiator is similar to a multiple, but to trigger the process all rules must be met.
Unique Start Events for Subprocesses
Some start events can only be added in subprocesses.
This initiator triggers the subprocess if there is an intermediate escalation event with a “launching” characteristic in the process.
This initiator is similar to an escalation, but it always interrupts the main process by launching an error.
This event is triggered when there needs to be some kind of recompense, which is initiated by a compensation entry in the main process diagram. Compensation is for undoing certain actions.
Intermediate events can affect the execution of a process and are used to divert the normal flow (exception flows) and impose constraints among other things.
Normal intermediate event
This event has no defined action but represents a change of state in a Process model.
This can be used to exchange messages between two pools. With HEFLO automation it can also be used for sending and receiving e-mails, web-service calls and other functions available via connectors.
This can be used as a border event in a task to define an exception flow. It can also be used to establish a flow restriction (for example “Wait 1 day”).
This is used to graphically represent a sequence flow continuity. The event that starts the “go to” must be a “throw” type and the link event that receives the redirect must be a “capture” type.
It can be used to broadcast a signal or to receive a signal broadcast from a border event. Signals are a form of decoupled communication between business processes.
Along with the timer intermediate event, this can be used as a border event to modify normal or off-task flow’s to represent a constraint.
Same as conditional and timer events, but with the possibility of containing several intermediaries and all must be met for the parallel to be executed.
Similar to the parallel, however this is triggered if only one of the contained intermediates is executed.
This type of event determines how and when a process ends. At this point in time it’s still possible to post messages to other processes.
This is a simple process end mark and ends the “token” of the flow. It’s worth remembering that a process can contain 1 or more tokens, which are paths in parallel.
It is formed by several other “finalizers”, which are all executed at the end of the process.
At the end of the process, it performs a message launch, which can be used to exchange messages between two pools.
At the end of the process it sends an escalation message so that capture events (an escalation initiator or an intermediate escalation capture) start complementary flows.
Sends a signal broadcast so that other processes initiate flows through signal initiators or signal capture intermediate events.
Terminates the process and sends an error signal for processing through an error subprocess.
Ends the process by closing all active “tokens”. This element is important if there are parallel paths in the process.
Ends the process or “token” and initiates the compensation flow, which is used to undo actions previously performed in the process.