Modular Design with Parent-Child Relationships
Upon completion of this module, you will be able to:
A sub-workflow is a child business process initiated by a parent workflow. Sub-workflows help meet complex business requirements without adding unnecessary complexity to existing workflows.
Sub-workflows must be configured on the same base record type as the initiating parent workflow. For example, if parent runs on Purchase Order, sub-workflow must also run on Purchase Order.
Use the Initiate Workflow action to start a sub-workflow from a parent workflow. This allows multiple workflows to process in parallel on the same record.
| Approach | Description | Use Case |
|---|---|---|
| Loose Coupling | Workflows process independently | Sequential processing without dependencies |
| Tight Coupling | Workflows have processing dependencies | Sequential processing with dependencies |
| Parallel Processing | Multiple workflows run simultaneously | Parallel approvals, concurrent tasks |
Loose coupling is when one component is not dependent on any other component. Each workflow processes independently and asynchronously.
LOOSE COUPLING PATTERN
┌─────────────┐
│ Workflow X │ ← Parent (orchestrator)
│ State 1 │
│ [Initiate A]│
│ State 2 │
│ [Initiate B]│
└─────────────┘
↓ ↓
┌──────────┐ ┌──────────┐
│Workflow A│ │Workflow B│
│(processes│ │(processes│
│ alone) │ │ alone) │
└──────────┘ └──────────┘
Workflow X is the orchestrator with minimal business logic—its purpose is to initiate sub-workflows A and B in sequence.
Tight coupling creates processing dependencies between workflows while still allowing sequenced execution.
TIGHT COUPLING PATTERN
┌─────────────┐
│ Workflow X │
│ State 1 │
│ [Initiate A]│───→ Workflow A completes
│ │ │
│ State 2 │←────────┘ (waits for A)
│ [Initiate B]│───→ Workflow B completes
│ │ │
│ State 3 │←────────┘ (waits for B)
└─────────────┘
Parent workflow X waits for child workflow A to complete before transitioning to State 2 and initiating workflow B.
Use workflow fields or record fields to communicate completion status between parent and child workflows. Configure transition conditions to wait for specific field values.
Parallel processing runs multiple workflows simultaneously on the same record.
PARALLEL PROCESSING PATTERN
┌─────────────┐
│ Workflow X │
│ State 1 │
│[Init A & B] │
└──────┬──────┘
┌────┴────┐
↓ ↓
┌──────────┐ ┌──────────┐
│Workflow A│ │Workflow B│
│(parallel)│ │(parallel)│
└──────────┘ └──────────┘
↓ ↓
┌──────┴──────┐
│ Workflow X │
│ State 2 │
│(waits both) │
└─────────────┘
A common use case where all approvals in both parent and child workflows must be completed before final approval is granted.
| Type | Behavior | Use Case |
|---|---|---|
| Synchronous | Parent waits for child to complete before continuing | Tight coupling, sequential dependencies |
| Asynchronous | Parent continues processing immediately after initiating child | Loose coupling, parallel processing |
Componentization—breaking complex workflows into smaller components—reduces complexity of any single workflow and results in easier maintenance.
To pass data between parent and child workflows, use standard or custom record fields—not workflow instance or state fields.