Initial version of SP changes for boundary events

Author: davevissermx

content/en/docs/refguide/modeling/application-logic/workflows/boundary-events.md

@@ -4,19 +4,15 @@ url: /refguide/workflow-boundary-events/
 weight: 20
 ---
 
-{{% alert color="info" %}}
-Interrupting timer boundary events are currently in beta. Certain features or attributes are subject to change and may contain bugs. For more information, see [Beta and Experimental Releases](/releasenotes/beta-features/).
-{{% /alert %}}
-
 ## Introduction
 
 Based on Business Process Model and Notation (BPMN) 2.0, boundary events are a type of event that is attached to the boundary of an activity (such as a task or a sub-process) to handle exceptional situations or are triggered by certain behaviors. 
 
 There are two main types of boundary events:
 
-* Non-interrupting boundary events: These events do not interrupt the ongoing activity. When triggered, they allow the activity to continue while simultaneously starting a new path from the boundary event. Use non-interrupting boundary events when the parent activity should remain active, but you would like to do something in parallel. For example, after 2 days, a reminder should be sent to the assigned user. As per BPMN 2.0 specification, non-interrupting boundary events are visualized as two dashed circles with an icon in the center.
+* **Non-interrupting boundary events**: These events do not interrupt the ongoing activity. When triggered, they allow the activity to continue while simultaneously starting a new path from the boundary event. Use non-interrupting boundary events when the parent activity should remain active, but you would like to do something in parallel. For example, after 2 days, a reminder should be sent to the assigned user. As per BPMN 2.0 specification, non-interrupting boundary events are visualized as two dashed circles with an icon in the center.
 
-* Interrupting boundary events (currently in beta): When these events are triggered, they interrupt the activity they are attached to, meaning that this activity will be aborted. The process flow is redirected to the boundary event's outgoing sequence path. Use interrupting boundary event in situations where further execution of the activity (and other following activities) is not required and an alternative path should be taken. For example, use an interrupting boundary event to start an escalation or a fast-track path when an activity is not completed 2 days after the due date. Or when the assigned user does not make a decision within 5 days, you want to abort the user task and continue the process with a pre-set decision. As per BPMN 2.0 specification, interrupting boundary events are visualized as two solid circles.
+* **Interrupting boundary events**: When these events are triggered, they interrupt the activity they are attached to, meaning that this activity will be aborted. The process flow is redirected to the boundary event's outgoing sequence path. Use interrupting boundary event in situations where further execution of the activity (and other following activities) is not required and an alternative path should be taken. For example, use an interrupting boundary event to start an escalation or a fast-track path when an activity is not completed 2 days after the due date. Or when the assigned user does not make a decision within 5 days, you want to abort the user task and continue the process with a pre-set decision. As per BPMN 2.0 specification, interrupting boundary events are visualized as two solid circles.
 
 Boundary Events are always displayed by 2 circles (either solid or dashed) and are linked by a dotted line to the parent activity. The icon inside the event indicates the type of event. For example, a clock indicates that it is a timer boundary event.
 
@@ -125,6 +121,16 @@ An interrupting boundary event path must end with an **End** event or a **Jump**
 When there are multiple boundary events attached to an activity and an interrupting boundary event is executed, all the scheduled boundary events will be aborted and all the boundary events that have already started will continue to run until the entire workflow ends.
 {{% /alert %}}
 
+## Nested jump rules
+Boundary events come with a specific set of rules for jumps when they are nested, the variations are working meant for both a modelled jump and a runtime ad-hoc jump. In the following table are the differences specified.
+
+|Parent | Child | Description|
+| -------- |-------- | ------- |
+|Interrupting | Interrupting | When an interrupting boundary event is nested inside an interrupting boundary event we are allowed to either jump out of the boundary event flow or end the workflow.|
+|Interrupting | Non-Interrupting | When an interrupting boundary event is nested inside an non-interrupting boundary event we are only allowed to jump out of the boundary event flow to it's parent flow.|
+|Non-Interrupting | Interrupting | When a non-interrupting boundary event is nested inside an interrupting boundary event we are only allowed to jump in the nested non-interrupting boundary event flow, this follows the same rules as the parallel split outcomes.|
+|Non-Interrupting | Non-Interrupting | When a non-interrupting boundary event is nested inside an non-interrupting boundary event we are only allowed to jump inside the nested non-interrupting boundary event flow, this follows the same rules as the parallel split outcomes.|
+
 ## Boundary Event Variables
 
 Boundary events have dedicated variables that can be used to get direct access to the values of the parent activity if it is either a user task or Call workflow activity. You can get information such as the parent activity's `DueDate`, which can be used in the boundary event flow and its expressions. For instance, you can use the expression `addDays($ParentTask/DueDate, -2)` to configure a timer boundary event so that it is triggered two days before the due date of its parent user task.
@@ -134,12 +140,6 @@ The list of variables is described below:
 * `$ParentTask` – the parent user task of the attached boundary event
 * `$CalledWorkflowInstance` – the parent Call workflow activity of the attached boundary event
 
-## Current Limitation {#limitation}
-
-The current release of boundary events is still under development and has the following limitation:
-
-* Non-interrupting timer boundary events currently have no recurrence (they are only executed once and will not repeat).
-
 ## Read more
 
 * [Workflows](/refguide/workflows/)

content/en/docs/refguide/modeling/application-logic/workflows/jump-to.md

@@ -44,7 +44,9 @@ After setting the objects, changes can be applied by calling a microflow contain
 
 Jumping to other activities has a limitation in parallel splits and in non-interrupting boundary event paths: it is not possible to jump into or out of a current parallel split or a non-interrupting boundary event path. However, it is possible to jump to other activities within a current parallel split or a non-interrupting boundary event path, including the end of the path. Activities in other parallel split or boundary event paths, as well as activities outside of the current path, are not available in the **System.WorkflowCurrentActivity_ApplicableTargets** association.
 
-For interrupting boundary event paths, it is possible to jump within or out of an interrupting boundary event path (to any activity in the parent path). If the interrupting boundary event is in a parallel split path, the boundary path must end with a **Jump** activity and then can jump back to the parent path (which is the parallel split path).
+For interrupting boundary event paths, it is possible to jump within or out of an interrupting boundary event path (to any activity in the parent path). If the interrupting boundary event is in a parallel split path or non-interrupting boundary event path, the boundary path must end with a **Jump** activity and then can jump back to the parent path (which is the parallel split / non-interrupting boundary event path).
+
+For more information about jumping rules in a boundary event path see [Nested jump rules](/refguide/workflow-boundary-events/#nested-jump-rules)
 
 ## Read More
 

content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/timer.md

@@ -38,14 +38,22 @@ The **Caption** describes what happens in this element. It is displayed under th
 
 {{% alert color="info" %}}
 This section is only applicable when **Timer** is used as a timer boundary event.
-
-This section is displayed if interrupting timer boundary events (beta) are enabled through Studio Pro **Preferences** -> **New features** -> **Workflow editor** > **Enable interrupting timer boundary events (beta)**.
 {{% /alert %}}
 
 The **Interrupting** property sets the timer boundary event to be either interrupting or non-interrupting.
 
 By default, it is set to **No**, which means that the timer boundary event is non-interrupting. When it is set to **Yes**, the timer boundary event is interrupting. For more information, see [Boundary Events](/refguide/workflow-boundary-events/).
 
+{{% alert color="info" %}}
+The following section is only applicable when **Timer** is used as a non-interrupting timer boundary event.
+{{% /alert %}}
+
+The **Recurrence** property allows a non-interrupting timer boundary event to execute multiple times when the specified interval has elapsed. The following parameters can be set.
+| Type | Description |
+| --- | --- |
+| Interval | You can set a certain duration for the timer. With the **Repeat every** setting, you can indicate the number of seconds, minutes, hours, days, weeks or months the timer's duration is. Possible values for the setting are:<br /><ul><li>Minutes</li><li>Hours</li><li>Days</li><li>Weeks</li><li>Months</li> </ul> |
+| Max occurrences | The maximum amount of occurrences. |
+
 ### Timer Section {#timer}
 
 The **Timer** property can be configured in two ways: you can set a certain duration or a date and time with an expression. When the workflow path reaches the timer, the configured duration or date and time will be scheduled to take effect.

content/en/docs/refguide/modeling/application-logic/workflows/workflow-engine.md

@@ -144,7 +144,9 @@ Each boundary event can have only one active instance of the event path at a tim
 
 If there are boundary event paths that have not yet been completed and the workflow's main path ends, the ongoing boundary event paths and their activities will be aborted. This will also occur if the workflow is aborted, retried, or restarted.
 
-With non-interrupting boundary events, the parent activity remains active/in-progress when an event is triggered (which means that the parent activity is not interrupted). For example, when a timer boundary event on a user task is triggered after 2 days, this task will remain in progress and the path defined below the timer boundary event is executed. When the boundary event path reaches the **End of Boundary Path**, the workflow will await the completion of the parent activity. 
+With non-interrupting boundary events, the parent activity remains active/in-progress when an event is triggered (which means that the parent activity is not interrupted). For example, when a timer boundary event on a user task is triggered after 2 days, this task will remain in progress and the path defined below the timer boundary event is executed. When the boundary event path reaches the **End of Boundary Path**, the workflow will await the completion of the parent activity.
+
+With interrupting boundary events, the parent activity is aborted and the modelled path will be executed. This path will then become the main path of the workflow. An interrupting boundary event has two possible ends (End Workflow or Jump-To). The End workflow activity can be switched to a Jump-to in any scenario. However when an interrupting boundary event is modelled in a parallel split or non-interrupting boundary event, only a jump can be used.
 
 #### Measures Against Endless Loops