Event Sub-Processes

Introduction

An event sub-process is a separate execution flow that is not part of the normal sequence flow of a workflow. It resides inside the workflow and starts executing upon receiving a specific trigger. It is crucial to understand that an event sub-process is part of the same workflow instance. It is not a separate workflow but a single workflow instance that can contain multiple concurrent processes.

Below is an example of an event sub-process, shown inside the dashed rectangle:

When to Use Event Sub-Processes

An event sub-process is similar to a boundary event, with the exception that an event sub-process can start at any time, whereas a boundary event can start only while the activity it is attached to is active. Choosing between a boundary event and an event sub-process is a common architectural crossroads.

Ideal Use Cases

Event sub-processes are particularly useful in the following scenarios:

• Global exception handling – Handling errors or cancellations that could occur at any point during the workflow execution.
• Isolated logic – Handling complex steps triggered by a specific event (for example, "Change of Address") without cluttering the main flow.
• Inline updates – Updating data in a long-running process without interrupting the primary state of the workflow.

When Not to Use Event Sub-Processes

• Sequential logic – If the logic must happen after a specific task, use a standard sequence flow.
• Conditional logic based on activity state – You may want to execute a flow only if a certain condition is met while a specific activity is active. A boundary event should be used here because it is triggered only if the activity it is attached to is active.
• Returning to a specific point – If you need to abort a specific task execution and resume it later, an interrupting boundary event is often more appropriate. Once the event is triggered, the boundary event can utilize a Jump activity to return to the original task.

How Event Sub-Processes Work

Lifecycle

An event sub-process is initialized (but not started) as soon as the main process starts and remains in a waiting state until a notification is received.

The workflow will NOT complete until all active execution paths, both the main flow and any triggered event sub-processes, have reached their respective end events.

Triggers and Notifications

Event sub-processes are triggered by a Notify workflow microflow activity. When the trigger is received, the sub-process becomes In Progress.

Interrupting vs. Non-Interrupting

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 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

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:

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.

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

Adding Event Sub-Processes

To add an Event sub-process to a workflow, follow these steps:

• Select an event sub-process from the Sub-processes section in the workflow Toolbox.

• Drag it onto a dashed drop zone adjacent to the main workflow process.

  

• The sub-process flow is contained within a dashed rectangle. This dashed border around the sub-process start event indicates that it is a non-interrupting sub-process.

• 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.

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.

Execution

To start an event sub-process, create a Notify workflow microflow activity and point it to the event sub-process start event.

Operational Lifecycle Management

An event sub-process is bound to the lifecycle of its parent workflow instance. Administrative actions and system-level events (such as errors or version conflicts) directly impact the execution state of active sub-processes.

The following table outlines how top-level workflow operations and system states affect any event sub-process that is currently In Progress:

Jump Rules

Event sub-processes have specific restrictions regarding Jump activity and Jump to:

• Between processes: It is not possible to jump into a sub-process from the main process (or vice versa), nor between different sub-processes.
• Within a sub-process: Jumps within the same sub-process are permitted.
  • Jump to Start Event: Aborts the current sub-process instance and returns it to a waiting state. If no other activities are in progress in the workflow instance after the jump, the workflow is aborted.
  • Jump to End Event: Completes the sub-process instance immediately. If no other activities are in progress in the workflow instance after the jump to the sub-process end event, the workflow is completed.

Domain Model Structure

To provide comprehensive monitoring, management, and auditing capabilities, the Mendix Workflow Engine utilizes specific system entities and associations. These ensure that every event sub-process instance is traceable back to its definition and correctly linked to the overall workflow lifecycle.

WorkflowSubProcessDefinition

The WorkflowSubProcessDefinition entity represents the metadata of a sub-process as defined in the workflow model.

Attributes

Associations

WorkflowSubProcess

The WorkflowSubProcess entity represents a specific runtime instance of an event sub-process. A WorkflowSubProcess object is created only after an event sub-process is notified and started its execution.

Attributes

Associations

WorkflowSubProcessState (Enumeration)

The WorkflowSubProcessState enumeration defines the possible lifecycle phases of a sub-process instance:

Read more

• Notify Workflow
• Workflow Versioning and Conflict Mitigation
• Jump activity
• Jump to