Event Based Gateway

At times, you need to execute some activities conditional on the outcome of someone else's decision. However, if the person required to reach a decision has not done so within a reasonable amount of time, your Process Instances might be locked.

An event-based gateway allows the execution of different activities based on a prior event. The event-based gateway is an exclusive gateway, meaning only one activity can be executed. We are going to use such a gateway in an approval process flow, illustrated below. An employee in the Front Office must, at some point in the larger process, submit a request for approval to another employee in the Back Office (Mike in this example).

The process logic might involve creating a new workitem for Mike. Mike is supposed to approve or reject a request — but his actions are unknown to the Front Office employee.

Since the approval Sub-Process is built using the internal messaging feature, and relies on sending WorkflowMessage Objects, this process can be modeled using an event-based gateway to listen for a specific message. This means the Process can react based on the occurrence of an event. Multiple events could possibly take place: receiving a WorkflowMessage Object which carries a message of approval, and another object carrying a rejection message. You could also listen for a signal which could be sent out in some other process like the approval sub-process.

The logic of the event-based gateway now triggers the following sequence of actions:

  1. Whichever event takes place first gets a token: Mike's decision dictates which outgoing connection is activated.
  2. All other modeled events after the event-based gateway never occur in that particular process instance (of course other running instances could observe a different event taking place).
  3. If your modeled activities are mutually exclusive, then time is no longer the deciding factor for the event to take place (that is, it is not necessarily the first event that gets the token, but the event corresponding to the decision made by Mike). In the case of mutually exclusive activities, two events are actually triggered but only one event will return true, based on the filter property in the event config (If $message == 'approve' Then Return true; Else Return false;)

"Emergency Exits"

If Mike does not, or cannot, decide immediately (or if both your message events are not triggering because of faulty filters), your Process Instance would be locked until Mike decides to either approve or reject. To prevent a situation where progress is dependent on Mike's current work speed (he could also be very busy and therefore he simply might not have the time to make the decision you desperately rely upon), there should always be an "emergency exit" event.

In our case, this is a timer intermediate event. The timer eventually runs out of time (let's say, after 48 hours) and is therefore the first event to take place if no decision has been made. This timer event renders the other events useless, and initiates a different sequence of actions. In our case, we might execute a script which reminds Mike to take a decision (maybe by sending him an email). Next, the Process would restart the event-based gateway logic.

Obviously, this Process could be modeled with other means: There is no overarching need to use an event-based gateway. However, it's a nice way to visually model different event outcomes which, for example, include an SLA ("Mike gets 48 hours or you escalate").

Keep in mind that even though you could work with an XOR gateway and a couple of script expressions, working with a visual approach such as an event-based gateway is often easier for business people to understand.