ExamFinch.com My Study

Study guide

8.2 Sub-Process Design: Synchronous vs. Asynchronous

Practice this exam

Appian Certified Associate Developer ACD101

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Platform Architecture & Environments

1.1 Appian Platform Architecture & Core Capabilities 1.2 Appian Designer, Applications & Object Containers 1.3 SDLC Environments, Deployment & Community Resources

2 Chapter 2: Security & Platform Governance

2.1 Group Hierarchies & Role-Based Access Control 2.2 Design Object Security & Dependency Tracking 2.3 Appian Design System & UX Governance

3 Chapter 3: Relational Data Modeling & CDTs

3.1 Custom Data Types (CDTs) & Schema Design 3.2 Data Stores, Entity Mapping & Table Publication

4 Chapter 4: Data Persistence Operations & Query Entity

4.1 Querying Relational Data with a!queryEntity 4.2 Data Modification & the Write to Data Store Entity Smart Service

5 Chapter 5: Records Architecture & Data Fabric

5.1 Record Types Architecture & Synced Data Sources 5.2 Record Relationships & Custom Record Fields

6 Chapter 6: Record Views, Actions & Record Queries

6.1 Record List Configuration, Headers & Views 6.2 Record Actions & Querying Records with a!queryRecordType

7 Chapter 7: Process Model Architecture & Task Design

7.1 Process Model Canvas, Lanes & Process Variables 7.2 User Input Tasks, Activity Chaining & Assignment 7.3 Script Tasks & System Smart Services

8 Chapter 8: Process Orchestration, Sub-Processes & Exception Handling

8.1 Workflow Gateways & Branching Logic 8.2 Sub-Process Design: Synchronous vs. Asynchronous 8.3 Process Escalations, Deadlines & Exception Events

9 Chapter 9: SAIL Interface Design & State Management

9.1 SAIL Framework & Component Hierarchy 9.2 Local Variables & Dynamic Refresh Behaviors 9.3 Rule Inputs, Component Parameters & Two-Way Binding

10 Chapter 10: Advanced Interface Components & Sites

10.1 Read-Only Grids and Editable Grid Layouts 10.2 Form Validations, Error Handling & Dynamic Display 10.3 Appian Sites, Navigation & Portal Configuration

11 Chapter 11: Expression Rules & Functional Data Manipulation

11.1 Expression Rule Architecture & Function Namespaces 11.2 List Processing & Looping with a!forEach 11.3 Conditional Logic & Decision Objects

12 Chapter 12: Query Optimization, Testing & Debugging

12.1 Expression Rule Testing, Assertions & Test Cases 12.2 Query Construction & Performance Best Practices 12.3 Error Handling, Type Coercion & Expression Debugging

8.2 Sub-Process Design: Synchronous vs. Asynchronous

Key Takeaways Explain This Topic AI

Subprocesses isolate variable scopes, but their memory lifecycle still depends on the child data-management configuration.

Synchronous sub-processes pause the parent process until the child completes, allowing bidirectional variable mapping (inputs and outputs) and seamless activity chaining.

Asynchronous sub-processes fire-and-forget, allowing the parent process to continue execution immediately with input-only parameter mapping and no output mapping.

Multiple instance sub-processes dynamically iterate over arrays to spawn parallel or sequential child instances for batch transactions like line items.

Activity chaining cannot enter an asynchronous child; the launch is unattended work and the parent path may continue its own chain.

Last updated: October 2026

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

The parent process reaches the Sub-Process node.

The parent process execution token pauses at the node.

The engine initializes the child process model, creating a new process instance in RAM with a new pp!id .

The child process executes its configured sequence of nodes from Start to End.

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.

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

The parent process reaches the Sub-Process node.

The engine spawns the child process instance in RAM.

The parent does not wait: The parent process execution token advances immediately to the subsequent node in the parent model without pausing.

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

Run one instance for each item in an array: The developer selects an array process variable (e.g., pv!lineItems ).

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

Architectural Feature Synchronous Sub-Process Asynchronous Sub-Process Multiple Instance Sub-Process

Parent Process Token Pauses at node until child completes Advances immediately without waiting Configure when to move on after synchronous instances complete

Input Variable Mapping Supported (Parent -> Child parameters) Supported (Parent -> Child parameters) Supported (Passes individual array element per instance)

Output Variable Mapping Supported (Child -> Parent outputs) Not Supported (Outputs tab disabled) Supported for synchronous children; configure list output saves

Activity Chaining Fully supported across parent and child Cannot enter the asynchronous child; parent path may continue chaining Requires appropriate MNI, assignment, and chain configuration

Process Engine Footprint Depends on data held and configured child cleanup Depends on child data, lifetime, and cleanup Moderate-to-High (Scales with number of spawned instances)

Typical Use Cases Approval workflows, wizard forms, modular business rules Audit logging, email alerts, background calculations Processing invoice line items, multi-party reviews

Realistic Workflow Scenario: Vendor Invoice Processing

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

A parent process AP_PM_InvoiceIngestion receives a vendor invoice with 15 line items.

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.

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.

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

Warning

Common Exam Trap 1 (Outputs on Asynchronous Sub-Processes): You cannot configure output variable mappings on an Asynchronous Sub-Process node. If an exam question asks how to retrieve data back from an asynchronous sub-process into the parent process via standard node outputs, the answer is that it cannot be done; output mapping requires a Synchronous Sub-Process.

Warning

Common Exam Trap 2 (Activity Chaining Across Asynchronous Nodes): Activity chaining cannot enter an asynchronous child process. The chain cannot enter the asynchronous child; the asynchronous launch is treated as unattended work on the parent path.

Warning

Common Exam Trap 3 (Sub-Process Parameter Flag): For a child sub-process to receive values from a parent process, the child process variables must have their "Parameter" checkbox selected in Process Model Properties. If this is omitted, the variable will not appear in the Sub-Process node's Inputs tab.

Tip

Memory Management Best Practice: Using synchronous sub-processes is a primary technique for reducing engine memory usage. Large datasets or intermediate calculation variables kept inside a child sub-process are purged from RAM when the child completes and archives, preventing parent process variable accumulation.

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