Merge branch 'development' of https://github.com/mendix/docs into development

Author: quinntracy

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.
 
@@ -62,23 +58,7 @@ To add a boundary event to the [above-listed activities](#supported-activities),
 
     {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/edit-dialog.png" alt="Adding boundary events through edit dialog" width="450" >}}
 
-To configure the properties of a boundary event, double-click the event to open its properties dialog box. For more information on how to configure the properties of a timer boundary event, see the [Properties](/refguide/timer/#properties) section in *Timer*.
-
-#### Enabling and Adding Interrupting Boundary Events (Beta)
-
-{{% alert color="info" %}}
-While you can add up to five non-interrupting boundary events to an activity, only one interrupting boundary event is allowed per activity.
-{{% /alert %}}
-
-Interrupting boundary events are currently in beta. To enable this feature, go to Studio Pro **Preferences** -> **New features** -> **Workflow editor** > **Enable interrupting timer boundary events (beta)**:
-
-{{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/enable-interrupting-boundary-event.png" alt="Enable interrupting boundary event" width="450">}}
-
-After interrupting boundary events are enabled, the **Boundary properties** section is displayed in the properties dialog box of a boundary event.
-
-By default, the **Interrupting** property is set to **No**, which means that the initially added event is a non-interrupting boundary event. To add an interrupting boundary event, set the **Interrupting** property to **Yes**. Click **OK** to save your configuration:
-
-{{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/interrupting-property.png" alt="Changing the type of boundary event" width="450">}}
+To configure the properties of a boundary event, double-click the event to open its properties dialog box. For more information on how to configure the properties of a timer boundary event, see [Boundary Properties](/refguide/timer/#boundary-properties).
 
 #### Implications of Changing the Boundary Event Type
 
@@ -88,8 +68,12 @@ For an existing boundary event, when you change its type from non-interrupting t
 
 After you confirm the change:
 
-* The boundary event is re-created as the specified type. As a result, new IDs are created. These IDs are used by the Mendix Runtime for conflict detection analysis.
-* The current activities on the boundary event path including the boundary event itself become incompatible and need to be restarted.
+* The boundary event is re-created as the specified type.
+* The workflow will become incompatible if the changed boundary event has already been executed. The workflow becomes incompatible for the following reasons:
+    * If the changed boundary event was non-interrupting, you will get the [Non-interrupting Boundary Event Path Removed](/refguide/workflow-versioning/#non-interrupting-boundary-event-path-removed) conflict.
+    * If the changed boundary event was interrupting, you will get the [Current Activity Removed](/refguide/workflow-versioning/#current-activity-removed) conflict.
+
+Boundary events are re-created upon type switch due to the execution limitations that exist for ongoing boundary events. For example, the parent activity will not be aborted when a non-interrupting boundary event starts. Once the boundary event type is changed to interrupting, the parent activity will stay in progress. That would allow the parent activity to have more than one ongoing interrupting boundary event. Vice versa, when an ongoing interrupting boundary event is changed to be non-interrupting, the parent activity is already aborted. Since a non-interrupting boundary event cannot end a workflow, it may remain active indefinitely unless explicitly aborted.
 
 ### Rearranging Boundary Events
 
@@ -125,9 +109,17 @@ 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 %}}
 
+## Jump Rules
+
+Boundary events come with a specific set of rules for jumps. These rules are applicable to both types of jumps - [Jumping to other activities in design time](/refguide/jump-activity/) and [Jumping in running workflow instances](/refguide/jump-to/). The rules are as follows:
+
+* Jump inside a boundary event: not possible
+* Jump outside a boundary event: not possible (a future plan is to make it possible to jump outside interrupting boundary events but only to the parent or grandparent path)
+* Jump within a boundary event: possible
+
 ## 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.
+Boundary events have dedicated variables that can be used by activities in the path of the boundary event 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.
 
 The list of variables is described below: 
 
@@ -136,9 +128,7 @@ The list of variables is described below:
 
 ## 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).
+* The already-scheduled timer boundary event will not be cancelled when a new one is scheduled for the same boundary event definition. For example, if a workflow instance has a scheduled timer boundary event, and you make a manual jump from a [Multi-User Task](/refguide/multi-user-task/) to itself, or a jump from the parent activity to another activity earlier in the executed path that causes it to run a second time, the timer boundary event will be scheduled again while the original timer is still pending. When the original timer expires, the boundary event will be triggered and the new timer will be disregarded. This is a limitation that will be fixed in the future.
 
 ## Read more
 

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

@@ -10,7 +10,7 @@ Running workflow instances can be manually changed while they are in progress. T
 
 {{% alert color="info" %}}
 
-This functionality is different from the [Jump activity](/refguide/jump-activity/) in workflows, which you can add from the **Toolbox** when you configure the workflow. The jumping to different activities functionality is something that you configure via microflow activities. 
+This functionality is different from the [Jump activity](/refguide/jump-activity/) in workflows, which you can add from the **Toolbox** when you configure the workflow. The jumping to different activities functionality is something that you configure via microflow activities.
 
 {{% /alert %}}
 
@@ -20,7 +20,7 @@ The [Generate Jump-to Option](/refguide/generate-jump-to-options/) microflow act
 
 {{< figure src="/attachments/refguide/modeling/application-logic/workflows/jump-to/jump-to-entities.jpg" class="no-border" >}}
 
-The **System.WorkflowJumpToDetails** object is associated with the **System.Workflow** through the **System.WorkflowJumpToDetails_Workflow** association, reflecting the workflow instance for which the information is generated. It also contains **System.WorkflowCurrentActivity** objects through the **System.WorkflowJumpToDetails_CurrentActivities** association. 
+The **System.WorkflowJumpToDetails** object is associated with the **System.Workflow** through the **System.WorkflowJumpToDetails_Workflow** association, reflecting the workflow instance for which the information is generated. It also contains **System.WorkflowCurrentActivity** objects through the **System.WorkflowJumpToDetails_CurrentActivities** association.
 
 The **System.WorkflowCurrentActivity** reflects the current activities of the workflow instance and gets the description of the current activity through the **System.WorkflowCurrentActivity_ActivityDetails** association. It also contains a list of activities which this activity can jump to through the **System.WorkflowCurrentActivity_ApplicableTargets** association. The **System.WorkflowCurrentActivity_JumpToTarget** association is empty.
 
@@ -42,11 +42,11 @@ After setting the objects, changes can be applied by calling a microflow contain
 
 ## Jumping to Other Activities in Parallel Splits or in Boundary Event Paths
 
-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.
+Jumping to other activities has a limitation in parallel splits and in boundary event paths: it is not possible to jump into or out of a current parallel split or boundary event path. However, it is possible to jump to other activities within a current parallel split or boundary event path, including the end of the path. Activities in other parallel splits or boundary event paths, as well as activities outside 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 more information about jumping rules in a boundary event path, see the [Jump Rules](/refguide/workflow-boundary-events/#jump-rules) section in *Boundary Events*.
 
 ## Read More
 
 * [Generate Jump-To Options](/refguide/generate-jump-to-options/)
-* [Apply Jump-To Option](/refguide/apply-jump-to-option/)
+* [Apply Jump-To Option](/refguide/apply-jump-to-option/)

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

@@ -31,6 +31,8 @@ The **Caption** describes what happens in this element. It is displayed under th
 You cannot use the **Jump** activity as the final step in a [Parallel split](/refguide/parallel-split/) path, a [Boundary Event](/refguide/workflow-boundary-events/) path, or the main workflow path without providing an alternative route. Doing so prevents the path from reaching its endpoint.
 {{% /alert %}}
 
+For more information about jumping rules in a boundary event path, see the [Jump Rules](/refguide/workflow-boundary-events/#jump-rules) section in *Boundary Events*.
+
 ### Common Section {#common}
 
 **Name** is the internal name of the element. When referring to the element in the app you will use this name. It must be unique within the workflow, but you can have two elements with the same name in different workflows. 

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

@@ -28,18 +28,17 @@ It can be used in the following two ways:
 * [General](#general)
 * [Boundary properties](#boundary-properties)
 * [Timer](#timer)
+* [Recurrence](#recurrence)
 * [Common](#common)
 
 ### General Section {#general}
 
 The **Caption** describes what happens in this element. It is displayed under the workflow element to make the **Timer** easier to read and understand without the need to add annotations.
 
-### Boundary Properties {#boundary-properties}
+### Boundary Properties Section {#boundary-properties}
 
 {{% 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.
@@ -57,6 +56,23 @@ The **Timer** properties are described in the table below:
 | Duration | You can set a certain duration for the timer. With the **Continue after** 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>Seconds</li><li>Minutes</li><li>Hours</li><li>Days</li><li>Weeks</li><li>Months</li> </ul> |
 | Expression | You can set a certain date and time for the timer by writing an expression via the **Continue at** setting.<br><br>For example, you can write `addDays([%CurrentDateTime%], 1)` to set tomorrow as the due date and time. To set a static date and time, you can use the expression `parseDateTimeUTC('2023-12-10T17:12:00.000', 'yyyy-MM-dd''T''HH:mm:ss.SSS')`.<br><br>You can also create a more complex timer. For example, you can set a timer based on a Boolean value (in this example, `isVIPUser`) from the provided workflow context entity: `if $WorkflowContext/isVIPUser then addDays([%CurrentDateTime%], 2) else addWeeks([%CurrentDateTime%], 2])`.<br><br>For more information on available expressions in Mendix, see [Expressions](/refguide/expressions/). |
 
+### Recurrence Section {#recurrence}
+
+{{% alert color="info" %}}
+The **Recurrence** property 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 run 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 minutes, hours, days, weeks or months the timer interval 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 number of occurrences, including the first boundary event execution.|
+
+{{% alert color="info" %}}
+When recurrence is set, the non-interrupting boundary event is first executed after the specified timer duration. From that point onward, it recurs with the set interval.
+{{% /alert %}}
+
 ### Common Section {#common}
 
 {{% alert color="info" %}}