Boundary Events

  • Updated

Boundary Events are events that sit attached to a Task's boundary. These events can have triggers configured to them and can start alternative or additional paths in a process application. 

Boundary Events can be added to a Task. They will be triggered according to which trigger is configured on the boundary event. A Boundary Event must have a Sequence Flow connected from the event and connected to another process symbol. When the Boundary Event is triggered, the process will continue along the connected Sequence Flow.

Task.png

Add a Boundary Event

  1. Add a Task to your process model.
  2. Right-Click on the Task and in the configuration panel click on the section Boundary Event. This will open a section in the configuration panel where you can pick a trigger
    Boundary_Event.png

Interrupting and non-interrupting

By default, all Boundary Events are set to Interrupting. This means that when the event is triggered, the activity that the boundary event is attached to will be canceled, is no longer available to those who have the task in their inbox, and the process will continue along the alternate exception path.

It is possible to make a Boundary Event Non-Interrupting. This setting is done on the Boundary Event and will change the look of the event. A Non-Interrupting Boundary Event can be configured with the same triggers as an interrupting boundary event. However, if the event is triggered, the task it is attached to will not be canceled. The process will start a parallel alternate exception path, but the activities that the Boundary Event was attached to will remain active and available for users to complete as normal.

Interrupting_or_Non-interrupting_.png

You can toggle a boundary event to be Interrupting or Non-interrupting by toggling the attribute Cancels activity On or Off. You can see whether or not the Boundary Event is one or the other by the way it looks.

Interrupting (Cancels activity - On)

Interrupting.png

Non-interrupting (Cancels activity - Off)

Non-interrupting.png

Multiple Boundary Events

It is possible to have more than one Boundary Event on a task. Follow the same instructions to add multiple boundary events. Each event can be configured independently and handle several events that start different exception paths giving you many possibilities within your process application.

Triggers

In order for something to happen in your deployed app you need to add a trigger. The following events are supported:

Manual Event

Manual events are triggered by users. They are useful when it is up to the user to decide and you do not want to direct the process flow based solely on automated logic. 

In the BPMN standard, there are no manual intermediate events, but there are manual tasks. However, we have found that adding the functionality for manual intermediate events, especially as non-interrupting boundary events, can be really useful. 

How to use Manual Events

blob1476430165090.png

Catching Manual Events 

Are used to trigger workflows by catching an action performed by a user, for example, pressing a button.  

blob1476439050974.png

Non-interrupting Catching Manual Boundary Events are used to trigger workflows by catching an action performed by a user, for example, pressing a button inside an active task.

Non-interrupting means that triggering the event will not cancel the task itself.

Process Automation currently supports:
- Catching manual events
- Catching non-interrupting manual boundary events.
If you wish to use an interrupting boundary event you can use a timer or a signal event instead. 

Read more on timer events.

Read more on signal events.

Configure a Manual Event

Manual events are not configurable themselves but will show up in the task view of any simultaneously active user tasks.

As such, if you want to use manual events to trigger workflows, you must model your process so that a workflow has active paths containing both a user task and a manual task at the same time like in this process model where the task is active at the same time as the manual event. The boundary event attached to the task is also active and can be triggered as long as the task is active. In order to trigger a manual event that event must be located in the same lane as the active role.

blob1476431222687.png

When the process reaches the task, the options for the user to trigger the manual tasks would be available in the task view. 

Trigger_Event_Manually.png

 

Selecting these options will trigger the manual events and the process will continue along its modeled path. Since the Manual Boundary Event is non-interrupting, the task will not be canceled by triggering it and will still be active and awaiting completion.

The non-interrupting manual boundary event can be triggered as many times as you wish as long as the task is still active.

Error Event

Error events are triggered by service and script task failure, for example, if a script task has been configured to copy the value of one field to another and the field name is changed in the form but not in the script configuration, then the script task will fail. If that script task has an error event connected, this will trigger the error event and redirect the process along the new path originating from the error event. 

In the BPMN standard, there are two kinds of error events:

  • Intermediate catching error events
  • End-throwing events

Error events can also be used as boundary events. 

How to use Error Events

blob1476452980054.png

Intermediate catching interrupting boundary error events are used to cancel script and service tasks that fail their execution. The intermediate (yellow) event catches an error generated by the script or service task which interrupts the task and triggers the boundary event.

Process Automation currently only supports intermediate catching interrupting boundary error events which can be attached to script and service tasks. 

Configure an Error Event

Error events are not configurable themselves but when attached as a boundary event of a script or service task which fails, they will trigger and interrupt the active workflow of the failed task and instead continue the flow to an associated outbound sequence flow.

blob1476687000338.png

Was this article helpful?

0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.