Subflows are reusable workflow fragments that can be created at the module or entity level (for example, Tickets, Changes, Problems, Releases, or Tasks) and plugged into event-based or scheduled workflows to encapsulate repeatable logic.


Subflows respect workspace scoping and module boundaries, accompanied with versioning and traceability, and define clear input or output contracts to pass data to and from parent workflows.


Availability: This feature is available for Pro and Enterprise Plans. 

Modules: Ticket, Change, Problem, Release, and Tasks.


In this article:


Availability and scope

  • Supported workflow types: Event-based and Scheduled (only for Pro and Enterprise plans).

  • Module/entity scope: Subflows are created per module/entity. A Ticket subflow can be reused only within Ticket workflows; a Change subflow only within Change workflows, and so on.


Exceptions

  • Software users module: Subflows are available only for scheduled workflows.

  • Alert workflows: Subflows are currently not supported for alert workflows.


Reuse and workspace scoping

Global subflows

  • Subflows can be used in global workflows and in the workflows inside any workspace.

  • Global workflows can use only global subflows (global workflows cannot use workspace/local subflows).

Workspace subflows

  • Subflows created inside a workspace can be used only within that workspace. They cannot be used in Global or other workspaces.

Module-level reuse

  • Subflows are reusable within the same module/entity only (for example, Ticket subflow cannot be reused in Change workflows).


Naming conventions

Global and local (workspace) subflows cannot share the same name.

  • Within the same workspace: A workflow (event or scheduled) and a subflow cannot have the same name; and the reverse also applies.

  • Across modules: Subflows can have the same name because they cannot be reused across modules.

  • Across workspaces: Subflows can have the same name (workspace-scoped isolation applies).


Limits and quotas

Subflows per workspace

  • Maximum of 250 subflows per workspace (Global or each workspace) for ESM accounts.

  • Example 1: If Global has 0 subflows, each workspace can have up to 250 subflows (for example, IT 250, HR 250, Facilities 250, and so on).

  • Example 2: If Global has 100 subflows, each workspace can have a maximum of 150 subflows.

Subflows per parent workflow

  • Maximum of 20 subflows can be connected/linked within a single parent workflow.

Nodes per subflow

  • Maximum of 25 nodes in a subflow.

  • Timers: Maximum of 5 timer nodes per branch in a subflow.

Inputs/outputs per subflow

  • Maximum of 15 inputs and 15 outputs per subflow.


Design a subflow

Select type and workspace

When creating a subflow:

  1. Select the module/entity (for example, Ticket or Change).

  2. Select the workflow type: Event or Scheduled.

Note: Applies to both workflow types unless restricted by module (for example, Software Users: Scheduled only).


Define inputs (data contract from parent workflow to subflow)

Inputs represent context from preceding nodes in the parent workflow where this subflow will be called.


Structure

Key, Type, and Value.


Note: Key and Type are defined in the subflow’s source configuration.



Value is intentionally left empty in the subflow (it acts as a placeholder to be provided by the parent workflow at the call-time).


Constraints

  • Inputs: Maximum of 15 inputs.

  • JSON parser outputs: Not all objects are supported for subsequent nodes. Subflows inherit the current limitations.

  • Complex objects: These are not supported; however existing capabilities remain as-is.

  • Web request response body: This can be provided as input with current platform capabilities.

  • Looping-related inputs: This will be added (as needed) in future versions.


Define nodes (logic inside the subflow)

Node configuration support (two types of values)

  • Subflow inputs that are defined.

  • Standard placeholders available per module/entity (for example, Ticket placeholders or Change placeholders).

Constraints and validations

  • Maximum of 25 nodes per subflow.

  • Maximum of 5 timer nodes per branch.

  • Condition node cannot be the last node in a subflow.

Approval node restrictions

  • A subflow containing an Approval node cannot be linked to a scheduled workflow.

  • If a subflow version (for example, V1) is linked to a scheduled workflow and you add an Approval in a draft (for example, V2), publishing will be blocked with a prompt explaining the restriction.

Web request and orchestration nodes

  • These can be the last nodes in a subflow.

  • If either of those is the last node, the output cannot be used by subsequent nodes in the parent workflow.

  • If the parent workflow needs to use the output, you should add at least one node after them inside the subflow.



Define outputs (data contract from subflow back to parent workflow)

Structure

Key, Type, and Value.


Note: Value is optional. If skipped, a secondary confirmation is required.


Constraints

Maximum of 15 outputs.


Use a subflow inside a parent workflow

Select and scope

  1. Drag and drop the Subflow block into the parent workflow, then select the subflow.

  2. (Inside workspace workflows) You can select subflows from both Global and the same workspace (matching module/entity).

  3. (Inside global workflows) You can select only Global subflows that are available.



Edit a subflow

  1. When you click Edit, a draft version of the subflow is created.

Note: Edits made to the draft will not affect the subflow that executes as part of parent workflows.

  1. After edits are complete, you can Publish the subflow.

Note: At this time, the list of workflows to which the subflow is already connected should be viewable.

Note:

  • A secondary confirmation is provided to publish the edited subflow.

  • Once published, the new version of the subflow starts executing as part of parent workflows it is linked to.

  • The previously active version of the subflow is archived and the new version is replaced as the active subflow.

  • The archived version will be deleted permanently 6 months after it was archived, if not updated.

  • No edits are allowed to the subflow inside the parent workflow except for the values in inputs.

Execution semantics

When a workflow is activated and calls a subflow:

  • Subflow nodes execute like any other workflow nodes.

  • Inputs are provided by previous nodes in the parent workflow via placeholders configured at the call-time.

  • Outputs are made available to subsequent nodes in the parent workflow.


Concurrency

If the subflow has multiple branches, the parent workflow resumes only after all branches in the subflow have completed (fork and join). The user interface (UI) displays a message on concurrencies.


Activity log

The following figure depicts the activity log of a subflow.



Audit log

The following figure depicts the audit log of a subflow.



Sync with Sandbox

Configuration setup

The Add Subflow (source configuration) option must be included in the configuration setup of the Sandbox environment, as each subflow is a separate configuration.



Sync behavior

When a Subflow source configuration is synced:

  • All parent workflow configurations in the target instance are automatically updated to include the latest version of the synced subflow.

  • Other nodes within the parent workflows remain unchanged during this update.


When a Parent workflow configured with a subflow is synced:

  • If the subflow already exists in the target instance:

    • The subflow is not synced again.

    • Only the parent workflow configuration is updated in the target instance.

  • If the subflow does not exist in the target instance:

    • The subflow needs to be synced from the source instance separately.

    • The synced subflow is automatically connected to the corresponding parent workflow in the target instance.

Edge cases

  • If a subflow with the same name and state exists in the trash of the target instance, synchronization will not occur when another subflow with the same name and state is attempted to be synced from the source.

  • This behavior is consistent with the current handling of workflows present in the trash.


Key callouts

  • Date/Date-time fields are not supported in input/output.

  • When a task subflow ends with an approval node, it will trigger approval for the parent ticket, and then the nodes after the subflow node in the task workflow will continue to execute.

  • Placeholders are not supported for web requests and orchestration app nodes if they are the last node in a subflow:

  • This is to avoid racing conditions during execution and handoffs from the subflow to the workflow.

  • Also, the output of these nodes cannot be used in subsequent parts of the workflow (as subflow outputs).

  • An event node immediately after a subflow is not supported in a workflow. This is to avoid resumption delays after subflow execution (especially when there are web requests and orchestration apps).

  • If a workflow containing subflow is deleted: 

  • If the subflow configuration is not deleted inside the subflow, execution will resume.

  • When a subflow exits and is handed over to the workflow, executions stop as the parent workflow configuration has been deleted.

  • The in-flight executions will continue but events which have a waiting duration like approval will not resume.

  • Traceability table counting mechanism:

  • Subflows configured inside a loop node or directly inside a workflow are still counted as one linked workflow only.

Unsupported scenarios

  • Nested subflows: A subflow cannot call another subflow.

  • Loop node inside a subflow: This is currently not supported.

  • Alert workflows: Subflows do not apply to alert workflows.

  • Scheduled workflows with approvals or timer nodes inside subflow: This is currently not allowed. If a subflow (already linked to a scheduled workflow) is edited to add an approval or timer node, publishing will be blocked.