diff --git a/content/en/docs/refguide/modeling/application-logic/workflows/boundary-events.md b/content/en/docs/refguide/modeling/application-logic/workflows/boundary-events.md
index 00b4ab1a8fd..6b2401e3ea4 100644
--- a/content/en/docs/refguide/modeling/application-logic/workflows/boundary-events.md
+++ b/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 can result in states that contradict BPMN 2.0 concepts. According to BPMN, an interrupting boundary event must abort its parent activity when triggered, meaning an activity cannot have more than one active interrupting boundary event. Converting an already-triggered non-interrupting boundary event to interrupting in place violates this rule: the parent activity remains in progress, resulting in an interrupting boundary event whose parent is never aborted. Conversely, converting an already-triggered interrupting boundary event to non-interrupting in place leaves it active on an already-aborted parent activity, contradicting the BPMN rule that a non-interrupting boundary event must not abort its parent.
 
 ### Rearranging Boundary Events
 
diff --git a/content/en/docs/refguide/modeling/application-logic/workflows/event-sub-processes.md b/content/en/docs/refguide/modeling/application-logic/workflows/event-sub-processes.md
index 48f921bb503..6373273a358 100644
--- a/content/en/docs/refguide/modeling/application-logic/workflows/event-sub-processes.md
+++ b/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 a start event of the specified type, along with all the event sub-process activities. The new start event can be triggered after the workflow is redeployed and is in progress.
+* The workflow becomes 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 can result in states that contradict BPMN 2.0 concepts. According to BPMN, an interrupting event sub-process cancels the parent process scope and all other active sub-processes when 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 for 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.
 
diff --git a/static/attachments/refguide/modeling/application-logic/workflows/event-sub-processes/security-dialog.png b/static/attachments/refguide/modeling/application-logic/workflows/event-sub-processes/security-dialog.png
new file mode 100644
index 00000000000..433bc7ecdbd
Binary files /dev/null and b/static/attachments/refguide/modeling/application-logic/workflows/event-sub-processes/security-dialog.png differ