Timer Event Sub-Process Recurrence

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

@@ -69,7 +69,7 @@ In the latter two cases, the **Select Event** dialog appears where you choose th
 
 {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/select-event.png" alt="Select Event dialog" max-width=80%  >}}
 
-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 boundary event properties, see the [Boundary Properties](/refguide/timer/#boundary-properties) section in *Timer* or the [Boundary Properties](/refguide/notification/#boundary-properties) in *Notification*.
+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 boundary event properties, see the [Interrupting Behavior](/refguide/timer/#boundary-properties) section in *Timer* or the [Interrupting Behavior](/refguide/notification/#boundary-properties) section in *Notification*.
 
 #### Adding a Boundary Event to an Ongoing Activity
 

content/en/docs/refguide/modeling/application-logic/workflows/event-sub-processes.md

@@ -51,7 +51,7 @@ The workflow will NOT complete until all active execution paths, both the main f
 Event sub-processes can be triggered by one of the following start event types:
 
 * **Notification start event** – The sub-process is triggered by a [Notify workflow](/refguide/notify-workflow/) microflow activity.
-* **Timer start event** – The sub-process is triggered automatically when the configured duration elapses or the configured date and time is reached. The timer configuration follows the same rules as the standalone [Timer](/refguide/timer/) activity. For more information, refer to the [Timer](/refguide/timer/#timer) section in *Timer*.
+* **Timer start event** – The sub-process is triggered automatically when the configured duration elapses or the configured date and time is reached. The timer configuration follows the same rules as the standalone [Timer](/refguide/timer/) activity. For more information, refer to the [Timer](/refguide/timer/#timer) section in *Timer*. A non-interrupting timer start event can also be configured to fire repeatedly; see the [Recurrence](/refguide/timer/#recurrence) section in *Timer*.
 
 When the trigger is received, the sub-process becomes **In Progress**.
 
@@ -64,13 +64,11 @@ Event sub-processes can be configured as either interrupting or non-interrupting
 
 #### Concurrency Limitation
 
-Mendix workflows currently support a **single concurrent instance** per defined event sub-process. If an event sub-process is already active, subsequent attempts to trigger it, either via the **Notify workflow** activity or when a timer fires again, are ignored. No new instances are created for that specific sub-process while one is **In Progress**. A new instance can be initiated only after the active sub-process has completed its execution path.
+Mendix workflows currently support a **single concurrent instance** per defined event sub-process. If an event sub-process is already active, subsequent attempts to trigger it via the **Notify workflow** activity are ignored. No new instances are created for that specific sub-process while one is **In Progress**. A new instance can be initiated only after the active sub-process has completed its execution path.
 
-If your workflow has multiple, distinct event sub-processes defined (for example, one for "Address Change" and one for "Document Upload"), each one can have its own active instance simultaneously. One being active does not prevent a different one from being triggered.
+A [recurring](/refguide/timer/#recurrence) timer start event is the exception: when it fires while an instance of its event sub-process is still **In Progress**, that instance is aborted and a new one is started. For more information, see [Recurrence While the Previous Instance Is Still Running](/refguide/timer/#recurrence-in-progress) in *Timer*.
 
-{{% alert color="info" %}}
-Currently, a timer start event fires only once. Support for recurring timers may be added in the future.
-{{% /alert %}}
+If your workflow has multiple, distinct event sub-processes defined (for example, one for "Address Change" and one for "Document Upload"), each one can have its own active instance simultaneously. One being active does not prevent a different one from being triggered.
 
 ## Getting Started
 

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

@@ -10,7 +10,7 @@ weight: 93
 
 **Notification** allows you to suspend a workflow path until the workflow is notified.
 
-It can be used in the following two ways:
+It can be used in the following ways:
 
 * **Notification** can be used as a standalone event on a workflow path. It suspends the workflow path until the workflow receives a notification. Use it as a standalone event when you want the path to be blocked until the notification is received. For example, when a workflow needs to wait for an external system to confirm that a payment is processed before continuing.
 
@@ -20,6 +20,8 @@ It can be used in the following two ways:
 
     {{< figure src="/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification/notification-boundary-event.png" alt="Notification boundary event" width="300" >}}
 
+* **Notification** can also be used as the start event of an [Event Sub-Process](/refguide/workflow-event-sub-processes/). Use it as an event sub-process start event when you want to start a separate flow whenever a notification is received, regardless of which activity of the main flow is currently active.
+
 {{% alert color="info" %}}
 The **Notification** element is an event and is represented as a circle in the workflow editor. This distinguishes it from the [Wait for Notification](/refguide/wait-for-notification/) activity, which is represented as a rounded square. Additionally, unlike **Wait for Notification**, it is not possible to attach boundary events to a **Notification** event.
 {{% /alert %}}
@@ -35,22 +37,26 @@ However, the entire parallel split remains suspended at the merge until the noti
 **Notification** properties consist of the following sections:
 
 * [General](#general)
-* [Boundary properties](#boundary-properties)
+* [Interrupting Behavior](#boundary-properties)
 * [Common](#common)
 
 ### General Section {#general}
 
 The **Caption** describes what happens in this element. It is displayed under the workflow element to make the **Notification** easier to read and understand without the need to add annotations.
 
-### Boundary Properties Section {#boundary-properties}
+### Interrupting Behavior Section {#boundary-properties}
 
 {{% alert color="info" %}}
-This section is only applicable when **Notification** is used as a notification boundary event.
+This section is only applicable when **Notification** is used as a notification boundary event or as the start event of a notification event sub-process.
 {{% /alert %}}
 
-The **Interrupting** property sets the notification boundary event to be either interrupting or non-interrupting.
+The **Interrupting** property sets the notification boundary event or notification event sub-process to be either interrupting or non-interrupting.
+
+By default, it is set to **No**, which means that the notification boundary event or event sub-process is non-interrupting. When it is set to **Yes**, the notification boundary event or event sub-process is interrupting. For more information, see [Boundary Events](/refguide/workflow-boundary-events/) and [Event Sub-Processes](/refguide/workflow-event-sub-processes/).
 
-By default, it is set to **No**, which means that the notification boundary event is non-interrupting. When it is set to **Yes**, the notification boundary event is interrupting. For more information, see [Boundary Events](/refguide/workflow-boundary-events/).
+{{% alert color="info" %}}
+Changing the interrupting behavior of an existing notification boundary event or notification event sub-process re-creates it, and it can make ongoing workflow instances incompatible. For more information, see *Implications of Changing the Interrupting Behavior* in [Boundary Events](/refguide/workflow-boundary-events/#event-type-change) or [Event Sub-Processes](/refguide/workflow-event-sub-processes/#event-type-change).
+{{% /alert %}}
 
 ### Common Section {#common}
 
@@ -62,11 +68,12 @@ This section is only applicable when **Notification** is used as a standalone ev
 
 ## Sending Notification
 
-To trigger the **Notification** event and resume the workflow path, use the [Notify Workflow](/refguide/notify-workflow/) microflow activity.
+To trigger the **Notification** event and resume the workflow path, use the [Notify Workflow](/refguide/notify-workflow/) microflow activity. The same activity is used to trigger a notification boundary event or to start a notification event sub-process.
 
 ## Read More
 
 * [Workflows](/refguide/workflows/)
 * [Wait for Notification](/refguide/wait-for-notification/)
 * [Notify Workflow](/refguide/notify-workflow/)
+* [Event Sub-Processes](/refguide/workflow-event-sub-processes/)
 * [Workflow Versioning and Conflict Mitigation](/refguide/workflow-versioning/)

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

@@ -11,7 +11,7 @@ aliases:
 
 **Timer** allows you to configure a certain duration or a specific date and time in a workflow.
 
-It can be used in the following two ways:
+It can be used in the following ways:
 
 * **Timer** can be used as a standalone event on a workflow path. It suspends the workflow path for a configurable duration or until a set date and time. Use it as a standalone event when you want the path to be blocked until the timer is triggered. For example, when a new salary legislation is about to take effect, a timer can be set until the date of effect to actually adjust the values in the system.
 
@@ -21,12 +21,14 @@ It can be used in the following two ways:
 
     {{< figure src="/attachments/refguide/modeling/application-logic/workflows/workflow-elements/timer/timer-boundary-event.png" alt="Timer boundary event" width="300" >}}
 
+* **Timer** can also be used as the start event of an [Event Sub-Process](/refguide/workflow-event-sub-processes/). Use it as an event sub-process start event when you want to start a separate flow at a configurable moment, regardless of which activity of the main flow is currently active.
+
 ## Properties
 
 **Timer** properties consist of the following sections:
 
 * [General](#general)
-* [Boundary properties](#boundary-properties)
+* [Interrupting Behavior](#boundary-properties)
 * [Timer](#timer)
 * [Recurrence](#recurrence)
 * [Common](#common)
@@ -35,19 +37,23 @@ It can be used in the following two ways:
 
 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 Section {#boundary-properties}
+### Interrupting Behavior Section {#boundary-properties}
 
 {{% alert color="info" %}}
-This section is only applicable when **Timer** is used as a timer boundary event.
+This section is only applicable when **Timer** is used as a timer boundary event or as the start event of a timer event sub-process.
 {{% /alert %}}
 
-The **Interrupting** property sets the timer boundary event to be either interrupting or non-interrupting.
+The **Interrupting** property sets the timer boundary event or timer event sub-process to be either interrupting or non-interrupting.
+
+By default, it is set to **No**, which means that the timer boundary event or event sub-process is non-interrupting. When it is set to **Yes**, the timer boundary event or event sub-process is interrupting. For more information, see [Boundary Events](/refguide/workflow-boundary-events/) and [Event Sub-Processes](/refguide/workflow-event-sub-processes/).
 
-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" %}}
+Changing the interrupting behavior of an existing timer boundary event or timer event sub-process re-creates it, and it can make ongoing workflow instances incompatible. For more information, see *Implications of Changing the Interrupting Behavior* in [Boundary Events](/refguide/workflow-boundary-events/#event-type-change) or [Event Sub-Processes](/refguide/workflow-event-sub-processes/#event-type-change).
+{{% /alert %}}
 
 ### 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.
+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. For a timer boundary event, the timer is scheduled when the activity it is attached to becomes active. For a timer event sub-process, the timer is scheduled when the workflow instance starts.
 
 The **Timer** properties are described in the table below:
 
@@ -57,26 +63,47 @@ The **Timer** properties are described in the table below:
 | 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/). |
 
 {{% alert color="info" %}}
-When the expression evaluates to `empty` or `null`, no timer is scheduled. If the timer is a standalone event, execution continues with the next activity. If it is a timer boundary event, the boundary event is skipped.
+When the expression evaluates to `empty` or `null`, no timer is scheduled. If the timer is a standalone event, execution continues with the next activity. If it is a timer boundary event or a timer event sub-process start event, the boundary event or event sub-process is skipped and is never triggered.
 {{% /alert %}}
 
 ### Recurrence Section {#recurrence}
 
 {{% alert color="info" %}}
-The **Recurrence** property is only applicable when **Timer** is used as a non-interrupting timer boundary event.
+The **Recurrence** property is only applicable when **Timer** is used as a non-interrupting timer boundary event or as the start event of a non-interrupting timer event sub-process.
 {{% /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.
+The **Recurrence** property allows a non-interrupting timer boundary event or event sub-process 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.|
+| Max occurrences | The maximum number of occurrences, including the first execution of the boundary event or event sub-process.|
 
 {{% 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.
+When recurrence is set, the non-interrupting boundary event or event sub-process is first executed after the specified timer duration. From that point onward, it recurs with the set interval.
 {{% /alert %}}
 
+#### Recurrence in a Paused Workflow
+
+A recurring occurrence is not executed while the workflow is **Paused** or **Failed**. Instead, the occurrence is rescheduled with the same interval, and the number of remaining occurrences is not reduced. This means that no occurrences are lost: the recurrence continues after the interval has elapsed again, and it still runs the configured number of times in total.
+
+For example, a recurring timer with an **Interval** of one hour and **Max occurrences** set to `2` starts at 9:00 AM:
+
+1. The first occurrence is executed at 9:00 AM. One occurrence remains, scheduled for 10:00 AM.
+2. The workflow is paused at 9:30 AM.
+3. At 10:00 AM, the second occurrence is due, but the workflow is paused. Therefore, it is not executed. It is rescheduled one hour later, to 11:00 AM, and the number of remaining occurrences stays at one.
+4. The workflow is unpaused at 10:30 AM.
+5. The second and final occurrence is executed at 11:00 AM.
+
+#### Recurrence While the Previous Instance Is Still Running {#recurrence-in-progress}
+
+A recurring timer can fire again while the flow started by its previous occurrence has not finished yet. In that case, the running flow is aborted and a new one is started:
+
+* **Timer boundary event** – The activity that is currently in progress on the path started by the previous occurrence is aborted, and a new path is started from the boundary event.
+* **Timer event sub-process** – The event sub-process instance started by the previous occurrence is aborted, and a new instance of the same event sub-process is started.
+
+If you want each occurrence to complete before the next one is triggered, make sure the **Interval** is longer than the expected duration of the flow that the timer starts.
+
 ### Common Section {#common}
 
 {{% alert color="info" %}}
@@ -116,6 +143,7 @@ When a **Timer** activity is removed from the workflow definition and the applic
 ## Read More
 
 * [Workflows](/refguide/workflows/)
+* [Event Sub-Processes](/refguide/workflow-event-sub-processes/)
 * [Add Date Function Calls](/refguide/add-date-function-calls/)
 * [Parse and Format Date Function Calls](/refguide/parse-and-format-date-function-calls/)
 * [Workflow Versioning and Conflict Mitigation](/refguide/workflow-versioning/)