Gateways are always a closed, hierarchical unit. Gateways may contain other gateways, but their end is always before the end of the outer gateway.

Under certain circumstances, however, it is desirable to jump back within a gateway, before the actual gateway, which is not technically possible. To make a jump back possible, the current gateway must first be exited so that a new rejection gateway can be created at the correct hierarchy level.

The following example of an initial process, in which a jump back after subprocess 3 before subprocess 2 is required, serves as an example.-

Open

However, this cannot be modelled directly, since sub-process 3 is located within a gateway. If the existing rejection (after sub-process 4 before sub-process 3) is to continue to exist despite this adjustment request, the only remaining option is to model the rejection outside the gateway and ensure that sub-process 4 is no longer run through when the conditions for the rejection after sub-process 3 are fulfilled.

This then results in the following logic.

Open

In the first step, a new gateway must therefore be created before sub-process 2. Then the following objects (sub-process 2 and the existing gateway) must be moved into the new gateway, so that the new gateway end is moved to the very end, as already described in Setting Up Rejections.-

So it is now basically possible to jump back to sub-process 2 after sub-process 3, but sub-process 4 would currently be started after the end of sub-process 3. To prevent this from happening, the start of subprocess 4 must be linked to conditions with the help of another gateway.-

For this rejection to work, it must be ensured that all 3 gateways involved have the correct conditions:

• Sub-process 4 must not start if a rejection is desired after sub-process 3

• The internal rejection gateway (after sub-process 4 before sub-process 3) must not trigger a retry if a rejection is desired after sub-process 3

• The new external rejection gateway must trigger a retry to jump to sub-process 2

These many conditions can become a problem if the conditions for the newly created rejection change at a later date, because not all relevant objects or formulas may be adjusted. For this reason, it makes sense to define the actual rejection logic only at a central point and then not to check the rejection logic again in the other formulas, but to query the process route instead. This is possible because each gateway provides the activated gateway. In this way, the following logic can be derived.

• The gateway Rejection checks whether a rejection should take place based on the result of sub-process 3. This determines the process route and prevents sub-process 4 from being started.

• The internal repetition may only be repeated if the gate No has been activated in the gateway rejection and the specific conditions are fulfilled

• The external rejection may only be repeated if the gate Yes was activated in the gateway rejection

By this logic, the conditions can be changed later on without any problems at one place, because the other conditions refer exclusively to the process route and thus remain independent of the implemented rejection conditions.

Rejection within 2 gateways

If a jump back to another gateway is to be made within a gateway, the principle is basically the same, but it must then not only be ensured that sub-processes are not processed after the jump back, but also that sub-processes are not run through again before the destination of the jump back.

The following outbound process serves as an example, where a jump back after sub-process 3 before sub-process 2 is required.-

Starting from the first example, this can only be achieved as follows:-

The principle is basically the same and here too, the actual condition for rejection after sub-process 3 before sub-process 2 should be defined once in the gateway immediately following and then only the process route should be evaluated. The result is then as follows:-

The special feature of this process flow is that in this case the process route is evaluated by the gateway Rejection 2 for gateway Rejection 1, and this gateway was not even activated the very first time it was run.

his means that there is no active gate from gateway Rejection 2, and a use in formulas returns an empty value in this case. So that this does not lead to subsequent problems, the gateway Rejection 1 should be structured in such a way that the gate No is activated by default (sub-process 1 is started) and only the gate Yes is linked to conditions. The Gate Yes should only be run through if the Gate Yes was run through in Gateway Rejection 2. If gateway Rejection 2 has never been processed, an empty value is returned and the condition (check for Yes) is therefore not correctly fulfilled.

This basically ensures that sub-process 1 is not run if a rejection occurs after sub-process 3. If, however, sub-process 2 is repeated after sub-process 2 (gateway Repetition 1), sub-process 1 would still not be processed, because the condition is still linked exclusively to Rejection 2. For this reason, the formula of gate Yes must be supplemented by Rejection 1, so that Rejection 2 is still checked, but it is also ensured that no repetition has taken place after sub-process 2. For this purpose, the gateway Repeat 1 provides the information whether the gateway was repeated. The formula must therefore look as follows: