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 ffe5ba2e80f..98bd81b43ba 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 @@ -56,19 +56,6 @@ Event sub-processes can be configured as either interrupting or non-interrupting * **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. -##### 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 invalid states. 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. - #### 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 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. @@ -90,6 +77,36 @@ To add an **Event sub-process** to a workflow, follow these steps: * The flow can contain the same types of activities as the main process flow (for example, **User Task**, **Call Microflow**, **Decision**). * It must start with a **Start** event (triggered by a notification) and end with at least one **End** event. +### Changing Sub-Process Start Event Type + +You can change the type of an existing sub-process start event using the context menu without having to delete and re-add it. To do this: + +1. Right-click the sub-process start event to open its context menu. +2. Click **Change event**. +3. Select one of the available options: + + {{< figure src="/attachments/refguide/modeling/application-logic/workflows/event-sub-processes/context-menu-change-event.png" alt="Changing sub-process start event type through context menu" width="450" >}} + +You can convert between the following supported start event types: + +* Notification (Interrupting) +* Notification (Non-Interrupting) +* Timer (Interrupting) +* Timer (Non-Interrupting) + +#### Implications of Changing the Interrupting Behavior {#event-type-change} + +For an existing sub-process start event, when you change its interrupting behavior from non-interrupting to interrupting or vice versa, you will be presented with a warning dialog. For example, when you change a sub-process 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 event sub-process is re-created with a start event of the specified interrupting behavior. The new sub-process 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 interrupting behavior change because in-place conversion can result in invalid states. 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. + ### Rearranging Event Sub-Processes In Studio Pro 11.11 and above, you can rearrange event sub-processes by right-clicking an event sub-process to open its context menu and clicking **Move event sub-process left** or **Move event sub-process right**, or you can use the Ctrl/Command + Left arrow or Ctrl/Command + Right arrow shortcut keys. diff --git a/static/attachments/refguide/modeling/application-logic/workflows/event-sub-processes/context-menu-change-event.png b/static/attachments/refguide/modeling/application-logic/workflows/event-sub-processes/context-menu-change-event.png new file mode 100644 index 00000000000..b2271175395 Binary files /dev/null and b/static/attachments/refguide/modeling/application-logic/workflows/event-sub-processes/context-menu-change-event.png differ 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 index 433bc7ecdbd..9603490af46 100644 Binary files a/static/attachments/refguide/modeling/application-logic/workflows/event-sub-processes/security-dialog.png and b/static/attachments/refguide/modeling/application-logic/workflows/event-sub-processes/security-dialog.png differ