8.2 Sub-Process Design: Synchronous vs. Asynchronous

Sub-Process Design: Synchronous vs. Asynchronous

Quick Summary: Sub-processes break down monolithic workflows into modular, reusable components with explicit input, output, and lifecycle boundaries. Synchronous sub-processes pause the parent process until the child completes, enabling bidirectional data exchange (inputs and outputs) and continuous activity chaining. Asynchronous sub-processes operate on a fire-and-forget basis, continuing parent execution immediately with input-only parameter mapping. Multiple Instance Sub-Processes dynamically spawn parallel or sequential child workflows for each element in an array.

---

Architectural Role of Sub-Processes

In enterprise application architecture, building an entire multi-stage business workflow inside a single process model leads to unmaintainable "monolithic" models. A monolithic process containing dozens of user tasks, integrations, gateways, and script tasks introduces severe design risks:

• Unnecessary Data Retention: Large variables and long-lived instances can increase memory use. Keep only the data needed by the workflow and configure cleanup for both parent and child processes.
• Low Reusability: Repeating the same steps in many models makes changes harder to maintain. Extract suitable common routines into reusable process models or rules.
• Testing & Debugging Friction: Isolating failures in a 60-node diagram requires extensive troubleshooting compared to unit-testing self-contained modular sub-processes.

By leveraging the Sub-Process Activity Node, architects decompose systems into high-level orchestrator processes and specialized child workflows. Each sub-process instance generates its own unique Process Instance ID (pp!id) and operates in its own execution thread.

+-------------------------------------------------------------------------+
|                        PARENT PROCESS INSTANCE                          |
|                           (pp!id: 100245)                               |
|                                                                         |
|  [Start] ---> [Validate Header] ---> [SUB-PROCESS NODE] ---> [Archive]  |
+---------------------------------------------+---------------------------+
                                              |
                     +------------------------+------------------------+
                     | (Synchronous Call)                              | (Asynchronous Call)
                     v                                                 v
+------------------------------------------+     +------------------------------------------+
|         CHILD SUB-PROCESS INSTANCE       |     |         CHILD SUB-PROCESS INSTANCE       |
|              (pp!id: 100246)             |     |              (pp!id: 100247)             |
|                                          |     |                                          |
| [Start] -> [Process Line Items] -> [End] |     | [Start] -> [Write Audit Log] -> [End]    |
|                                          |     |                                          |
| * Parent PAUSES and awaits completion    |     | * Parent CONTINUES immediately           |
| * Bidirectional data (Inputs & Outputs)  |     | * Input data ONLY (No Outputs)           |
| * Activity chaining supported            |     | * Chain cannot enter this child        |
+------------------------------------------+     +------------------------------------------+

---

Synchronous Sub-Processes - Tightly Coupled Orchestration

A Synchronous Sub-Process creates a blocking dependency between the parent process and the child instance.

Execution Lifecycle

1. The parent process reaches the Sub-Process node.
2. The parent process execution token pauses at the node.
3. The engine initializes the child process model, creating a new process instance in RAM with a new pp!id.
4. The child process executes its configured sequence of nodes from Start to End.
5. When the child process completes all required execution paths, the engine signals the waiting parent node. A nonterminating end on one parallel path does not necessarily complete the child.
6. Output variables are transferred from the child back into the parent, and the parent process token resumes execution along its outgoing sequence flow.

Bidirectional Variable Mapping

Synchronous execution allows full bidirectional data transfer between parent and child:

• Input Variables (Parent -> Child): The parent maps data into the child process model. The child process variables must be marked as Parameter (Parameter = Yes) in the child process model properties to accept incoming values.
• Output Variables (Child -> Parent): Upon completion, process variables from the child are mapped back into parent process variables on the Outputs tab of the Sub-Process node. This allows the parent to utilize calculated values, approval decisions, or generated record identifiers produced within the child.

Activity Chaining Across Synchronous Boundaries

To move from a parent task into a child task, use a synchronous, attended subprocess running in standard mode. Maintain the chain into the subprocess and configure Enable activity-chaining into all initial nodes in the subprocess on its Setup tab. For a child without a start form, this option is required to display the first attended activity. With it selected, the initial internal connection need not separately be chained, although Appian recommends consistent chained flows.

Keep the subsequent child flows chained as appropriate, and ensure the next attended task is assigned to the current user. Configure the return flows if the chain must continue into the parent. Test the actual sequence; merely selecting Synchronous does not guarantee navigation. Appian skips a child start form when following an activity chain into the subprocess.

Asynchronous Sub-Processes - Fire-and-Forget Decoupling

An Asynchronous Sub-Process establishes a non-blocking, decoupled execution relationship.

Fire-and-Forget Execution Mechanics

1. The parent process reaches the Sub-Process node.
2. The engine spawns the child process instance in RAM.
3. The parent does not wait: The parent process execution token advances immediately to the subsequent node in the parent model without pausing.
4. Both parent and child processes execute concurrently and independently in separate engine threads.

Input-Only Parameter Mapping Constraints

Because the parent process does not wait for the child process to complete, output variable mapping is not provided by the ordinary asynchronous subprocess result mapping:

• In Appian Designer, the Outputs tab of an Asynchronous Sub-Process node is permanently disabled.
• The parent can pass initial parameter data down to the child via the Inputs tab, but it cannot receive any values back.

Activity Chaining Restrictions

Activity chaining cannot enter an asynchronous child process. The browser chain cannot enter that asynchronous child. The launch node is unattended work, so the parent's own chained path may continue to its next eligible attended task.

Ideal Architectural Use Cases for Asynchronous Sub-Processes

• Audit & Event Logging: Writing immutable compliance logs or business activity audit entries to a relational table or external system.
• Non-Blocking Notifications: Sending batch emails, SMS alerts, or push notifications that should not delay workflow progression.
• Heavy Background Computations: Triggering complex data aggregations, nightly snapshot generation, or document conversions that do not affect immediate user interactions.
• Independent Lifecycle Operations: Launching auxiliary workflows (e.g., ordering replacement parts) that proceed on their own distinct timeline independently of the originating case.

---

Multiple Instance Sub-Processes (Array Iteration / MIK)

Enterprise processes frequently handle collections of data—such as a list of invoice line items, an array of candidate background checks, or multiple departmental review tasks. In traditional programming, this is handled with a for loop. In Appian process models, looping via sequence flows can cause engine memory thrashing. The recommended best practice is configuring Multiple Instances on a Sub-Process node (often historically called MIK - Multiple Instances of a Known process).

Configuring Multiple Instances

On the Sub-Process node's Other tab, developers enable the option: "Automatically run multiple instances of this node":

1. Run one instance for each item in an array: The developer selects an array process variable (e.g., pv!lineItems).
2. Execution Mode:
   • Run all instances simultaneously (Parallel): The engine spawns all child sub-process instances at the exact same moment. This delivers concurrent execution subject to resource constraints for independent tasks (e.g., validating 10 line items against external ERP APIs concurrently).
   • Run instances one at a time (Sequential): The engine spawns the first instance, waits for it to complete, then spawns the second, continuing sequentially through the array.

Collecting and Merging Outputs

When executing synchronous multiple instances, outputs from every child instance can be consolidated back into an array variable in the parent process:

• The system variable tp!instanceindex identifies the index of the specific instance currently executing.
• Outputs can be appended into an array or written directly to specific indices (e.g., pv!processedResults[tp!instanceindex]).

Multiple Instance Execution (Parallel):
Parent Array: pv!vendorInvoices = [Inv-101, Inv-102, Inv-103]
                  |
                  +---> Sub-Process Instance 1 (Inv-101) ---> Output [Status: Approved]
                  +---> Sub-Process Instance 2 (Inv-102) ---> Output [Status: Rejected]  ===> Consolidated pv!statusArray
                  +---> Sub-Process Instance 3 (Inv-103) ---> Output [Status: Approved]

Memory Guardrails for Multiple Instances

While multiple instances are powerful, spawning thousands of sub-process instances simultaneously can cause engine memory spikes. For massive datasets (> 500 items), developers should process records in batches or leverage expression-based database writes (Write to Data Store Entity / Write Records) rather than instantiating hundreds of full process instances.

---

Sub-Process Pattern Comparison Matrix

---

Realistic Workflow Scenario: Vendor Invoice Processing

A global accounts payable automation workflow illustrates the combined use of sub-process patterns:

1. A parent process AP_PM_InvoiceIngestion receives a vendor invoice with 15 line items.
2. The parent executes a Synchronous Sub-Process AP_PM_ValidateVendorData to verify vendor tax identification and bank routing details against the database. The parent waits for this sub-process to return pv!isVendorActive before proceeding.
3. The parent reaches a Synchronous Multiple Instance Sub-Process AP_PM_ProcessLineItem, configured to run simultaneously for each item in pv!invoiceLineItems. Fifteen child instances execute in parallel, performing three-way matching against purchase orders. Configure the output saves to collect all 15 results in pv!lineItemValidationResults. Choose an append or indexed-save strategy deliberately; an ordinary overwrite can retain only the last completed result.
4. Finally, the parent triggers an Asynchronous Sub-Process AP_PM_LogAuditTrail to write audit entries to the enterprise data warehouse. Because audit logging is a background operation, the parent does not wait for it to finish and immediately completes the invoice settlement workflow.

---

Exam Traps & Architecture Guidelines

Source checked 2026-10-18: Appian subprocess behavior.