Refer to the following page for a summary of all Workflow Nodes: RSA Governance & Lifecycle Workflow Nodes Summary.

 

Product Area: Workflows

Workflow Node: Subprocess articles

Applies to Workflow Types: All (Requests, Reviews, Rules)

Time to apply: <15 minutes

Impact: High positive impact for workflow reuse and maintainability. Low risk to workflow execution when properly configured.

 

Purpose:

Subprocess Node is used to invoke another workflow (process) as a subprocess of the current workflow. This allows common workflow logic to be reused and helps simplify and modularize complex workflows.

 

Summary:

The Subprocess Node allows a parent workflow to call another existing process as a child job. The child process executes independently while remaining linked to the parent workflow. Once the subprocess completes, control returns to the parent workflow.

This approach avoids duplication of common logic and improves long-term maintenance.

 

Key use:

To reuse shared workflow logic, compartmentalize complex processes, and improve workflow maintainability.

 

Usage:

• Reuse common workflow steps across multiple processes
• Break large workflows into smaller, manageable components
• Centralize maintenance of shared workflow logic

 

General Notes/Benefits:

• Promotes modular workflow design
• Reduces duplication and maintenance effort
• Improves readability of complex workflows
• Supports parent-child job execution

 

Configuration:

The Subprocess node can be found under the Template Toolbar, within the Common section. To add the node, single-click the Subprocess icon in the left-side panel, then double-click anywhere in the workflow canvas.

Subprocess Node Properties

General Section

1. 1. Name
      • Display name of the Subprocess node on the workflow canvas
      • Does not need to be unique
      • This field is mandatory (the node name is Subprocess by default)
      • Recommended to keep the name generic
   2. Description
      • Used to describe the purpose of the subprocess
      • Helpful for future reference, maintenance, and troubleshooting
   3. Enabled
      • Controls whether the node is active or disabled in the workflow
      • When the node is Disabled, the Subprocess node is skipped entirely and the workflow does not execute the subprocess workflow
      • User Cases:
        • Enable the node when:
          • Subprocess execution is required
          • Workflow logic depends on child workflow execution
        • Disable the node when:
          • Temporarily bypassing subprocess execution for testing
          • Troubleshooting workflow behavior

 

Status Section

The Status section contains the following status messages:

• • Planned (Possible)
  • Completed
  • Planned (Definite)

1. 1. Planned (Possible)
      • Displays a message before the workflow reaches the Subprocess node.
      • Can indicate a potential upcoming Subprocess execution.
   2. Planned (Definite)
      • Displays a message before the workflow reaches the Subprocess node.
      • Indicates an expected upcoming Subprocess execution as part of the workflow path.
   3. Completed
      • Displays a message only after the Subprocess node has executed successfully.
      • Confirms that the subprocess workflow has been invoked.

Recommendation:

• • • Leave both Planned options (Possible and Definite) empty and populate only the Completed status message to display confirmed execution details and avoid confusion.

• • • • The Planned (Possible) message will be displayed even though at this point the workflow has not yet transitioned through the node. This is a way to provide some information about a potential next step in the process, which is upcoming.

• • • • Completed will populate the message only after the workflow has successfully transitioned through/past the node.

Subprocess Section

The Subprocess section allows you to control which workflow is selected as the subprocess and when it should be executed. This section contains toggle options and execution controls that determine subprocess behavior.

1. 1. Only Show Workflows Similar to the Current Workflow
      • This toggle filters the list of available workflows
      • When enabled, only workflows that are compatible with the current (parent) workflow are displayed
      • Helps prevent incorrect or incompatible subprocess selection
      • Recommended to keep enabled to reduce configuration errors

1. 2. Workflow (Subprocess Selection)

1. 1. • Allows selection of the workflow that will be executed as the subprocess
      • The selected workflow becomes the child process when this node is executed
      • This workflow must already exist in the system

3. Subprocess Execution Control

This section determines when the selected subprocess workflow is executed.

Workflow Will Process All Changes

• • When selected, the subprocess workflow is always executed when the SubProcess node is reached
  • No condition evaluation is performed
  • Suitable for mandatory subprocess execution scenarios

The Subprocess section is configured with the following options:

• • Only show workflows similar to the current workflow: Enabled
  • Workflow selected: Sample - Manual Escalations
  • Execution option: Workflow will process all changes

When Workflow will process all changes is selected:

1. • The selected subprocess workflow (Sample - Manual Escalations) is executed every time the Subprocess node is reached
   • No conditions are evaluated

Workflow Will Process Changes Where

• • Allows conditional execution of the subprocess
  • A condition must be defined in this section

Behavior:

• • If the condition evaluates to TRUE, the subprocess workflow is executed
  • If the condition evaluates to FALSE, the subprocess workflow is not executed, and the parent workflow continues without invoking the subprocess

This option is useful when subprocess execution is required only for specific scenarios or data conditions.

From the example shown in the image, the condition is configured as:

• • Left Operand: User.Department
  • Comparison: =
  • Right Operand: Development

How this works

• • When the Subprocess node is reached, the workflow evaluates the condition:
    User.Department = Development
  • If TRUE: The subprocess workflow "Sample - Manual Escalations" is executed.
  • If FALSE: The subprocess workflow is skipped, and the parent workflow continues along its normal path.

Connector

• • The Connector field (for example, NONE, AND, OR) is used when multiple conditions are configured.
  • In this example, only one condition is present, so the connector is set to NONE.

Practical Use Case:

This configuration is useful when a subprocess should only run for specific users or scenarios.

Example use case:
Run a manual escalation workflow only for users belonging to the Development department, while skipping it for all other departments. 

 

Self-Looping Panel Section

The Subprocess node supports a self-looping transition, which allows the workflow to loop back to the same node and re-execute the subprocess if required.

By default, the self-loop transition should be kept Unconditional. This ensures normal execution of the Subprocess node without introducing unnecessary looping behavior.

If re-execution of the subprocess is required, the self-loop transition must be explicitly configured using one of the following types:

• • Conditional: The workflow loops back to the Subprocess node only when the defined condition evaluates to TRUE (for example, when the subprocess needs to be re-invoked based on processing results).
  • Completion Code: The workflow loops back based on a specific completion code returned by the Subprocess node execution.

Only when a Conditional or Completion Code-based self-loop is configured will the workflow re-enter and re-execute the subprocess. Otherwise, the workflow continues through the normal outbound transitions.