Interrupting Notification Event Sub-Process

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

@@ -65,7 +65,7 @@ To configure the properties of a boundary event, double-click the event to open
 
 When a boundary event is added to an ongoing activity, any workflow instances currently executing that activity will schedule the new boundary event accordingly. The only exception occurs when an ongoing boundary event is removed from the ongoing activity, the workflow is redeployed, and then the removal is reverted. In this case, the re-added boundary event will not be scheduled.
 
-#### Implications of Changing the Boundary Event Type
+#### Implications of Changing the Boundary Event Type {#event-type-change}
 
 For an existing boundary event, when you change its type from non-interrupting to interrupting or vice versa, you will be presented with a warning dialog. For example, when you change a boundary event from non-interrupting to interrupting, you will see the following warning dialog:
 
@@ -78,7 +78,7 @@ After you confirm the change:
     * 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.
+Boundary events are re-created upon type switch because in-place conversion would produce states that contradict BPMN 2.0 concepts. Per BPMN, an interrupting boundary event must abort its parent activity upon firing, which means an activity can never have more than one interrupting boundary event active at the same time. Converting an already-triggered non-interrupting boundary event to interrupting in place would violate this rule: the parent activity would still be in progress, resulting in an interrupting boundary event whose parent was never aborted. Conversely, converting an already-triggered interrupting boundary event to non-interrupting in place would leave it active on an already-aborted parent activity — contradicting the BPMN concept that a non-interrupting boundary event must never abort its parent.
 
 ### Rearranging Boundary Events
 

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

@@ -53,16 +53,25 @@ Event sub-processes are triggered by a [Notify workflow](/refguide/notify-workfl
 
 Event sub-processes can be configured as either interrupting or non-interrupting, depending on how they interact with the main process flow.
 
-* **Interrupting (solid line)** – Immediately cancels the main process flow.
+* **Interrupting (solid line)** – Immediately cancels the main process flow and all ongoing sub-processes within the workflow instance.
 * **Non-Interrupting (dashed line)** – Runs in parallel with the main flow.
 
-{{% alert color="info" %}}
-Currently, Mendix only supports the non-interrupting variant of event sub-processes. Support for interrupting event sub-processes is planned for a future release.
-{{% /alert %}}
+##### Implications of Changing the Sub-Process Start Event Type {#event-type-change}
+
+For an existing event sub-process, when you change the type of its start event from non-interrupting to interrupting or vice versa, you will be presented with a warning dialog. For example, when you change a notification start event from non-interrupting to interrupting, you will see the following warning dialog:
+
+{{< figure src="/attachments/refguide/modeling/application-logic/workflows/event-sub-processes/security-dialog.png" alt="Security Dialog when changing type" width="450">}}
+
+After you confirm the change:
+
+* The sub-process is re-created with the start event of the specified type together with all the event sub-process activities. The new start event can be triggered after the workflow is redeployed and becomes in progress.
+* The workflow will become incompatible if the changed event sub-process is already being executed in one of the ongoing workflow instances.
+
+The event sub-process is re-created upon type switch because in-place conversion would produce states that contradict BPMN 2.0 concepts. Per BPMN, an interrupting event sub-process cancels the parent process scope and all other active sub-processes the moment it is triggered, while a non-interrupting one runs in parallel without affecting them. These are mutually exclusive execution models: an event sub-process instance belongs to exactly one of them from the moment it starts. Changing the type in place on an already-active instance would leave it in a state that is neither valid interrupting nor valid non-interrupting behavior, violating the fundamental BPMN distinction between the two.
 
 #### Concurrency Limitation
 
-Mendix workflows currently support a **single concurrent instance** per defined event sub-process. If a non-interrupting event sub-process is already active, subsequent attempts to trigger that same sub-process via the **Notify workflow** activity will return `false`. No new instances will be created for that specific sub-process while one is **In Progress**. A new instance can only be initiated once 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 that same sub-process via the **Notify workflow** activity will return `false`. No new instances will be created for that specific sub-process while one is **In Progress**. A new instance can only be initiated once 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.