# Orchestration Pattern: Parent-Child > The Parent-Child pattern is an orchestration approach where a parent flow coordinates multiple child subflows, each handling a specific responsibility. - Skill: `tools-only/orchestration-pattern-parent-child-2` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add tools-only/orchestration-pattern-parent-child-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/orchestration-pattern-parent-child-2/raw - Safety review: pending (external: skill-scanner PASS, skillspector WARNING) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tools-only (https://skillmd.com/u/tools-only) - Updated: 2026-09-29 - Page: https://skillmd.com/skills/tools-only/orchestration-pattern-parent-child-2 --- # Orchestration Pattern: Parent-Child ## Overview The **Parent-Child pattern** is an orchestration approach where a parent flow coordinates multiple child subflows, each handling a specific responsibility. This creates modular, maintainable automation that's easier to test, debug, and enhance. ## When to Use This Pattern ✅ **Use Parent-Child when:** - Complex automation has multiple distinct steps - Different teams own different parts of the logic - You need to reuse steps across multiple parent flows - Testing and debugging large flows is difficult - Changes to one step shouldn't require retesting everything ❌ **Don't use when:** - Automation is simple with 1-2 steps - All logic is tightly coupled - Performance is critical (minimal subflow overhead acceptable) ## Real-World Example: Account Industry Change ### Business Requirement When an Account's Industry changes: 1. Update all related Contacts with the new Industry 2. Update all related Opportunities with Industry-specific Stage 3. Send notification to Account Owner 4. Log the change for audit purposes ### ❌ Monolithic Approach (Anti-Pattern) One large flow with everything inline: ``` RTF_Account_IndustryChange ├── Get Related Contacts (150+ records) ├── Loop Through Contacts │ └── Update Each Contact (DML in loop! ❌) ├── Get Related Opportunities ├── Decision: Industry = "Technology"? │ ├── Yes → Update Stage to "Discovery" │ └── No → Update Stage to "Qualification" ├── Loop Through Opportunities │ └── Update Each Opportunity (DML in loop! ❌) ├── Send Email to Owner └── Create Audit Log Problems: - 400+ lines of XML - DML in loops causes bulk failures - Can't reuse Contact update logic elsewhere - Testing requires full end-to-end scenario - Debugging is painful ``` ### ✅ Parent-Child Approach (Best Practice) Break into coordinated flows: ``` Parent: RTF_Account_IndustryChange_Orchestrator ├── Child: Sub_UpdateContactIndustry (reusable) ├── Child: Sub_UpdateOpportunityStages (reusable) ├── Child: Sub_SendEmailAlert (from library) └── Child: Sub_CreateAuditLog (reusable) Benefits: - Each child is 50-100 lines - Each child can be tested independently - Children can be reused in other flows - Clear separation of concerns - Easy to add/remove steps ``` ## Implementation ### Parent Flow: RTF_Account_IndustryChange_Orchestrator ```xml 65.0 Parent orchestrator that coordinates industry change automation. Calls child subflows for each responsibility. RTF_Account_IndustryChange_Orchestrator BuilderType LightningFlowBuilder AutoLaunchedFlow 0 0 Update_Contacts

Update RecordAfterSave Draft Update_Contacts Update Related Contacts 0 0 Update_Opportunities Sub_UpdateContactIndustry varAccountId $Record.Id varNewIndustry $Record.Industry Update_Opportunities Update Related Opportunities 0 0 Notify_Owner Sub_UpdateOpportunityStages varAccountId $Record.Id varIndustry $Record.Industry Notify_Owner Notify Account Owner 0 0 Create_Audit_Log Sub_SendEmailAlert varEmailAddresses $Record.Owner.Email varEmailSubject Account Industry Updated varEmailBody Account {!$Record.Name} industry changed to {!$Record.Industry}. Related records have been updated. Create_Audit_Log Create Audit Log 0 0 Sub_CreateAuditLog varObjectName Account varRecordId $Record.Id varFieldChanged Industry varNewValue $Record.Industry ``` ### Child Flow 1: Sub_UpdateContactIndustry ```xml 65.0 Updates Industry field on all Contacts related to an Account. Bulkified and reusable. Sub_UpdateContactIndustry AutoLaunchedFlow Get_Related_Contacts Get Related Contacts 0 0 false Check_If_Contacts_Found and AccountId EqualTo varAccountId false

true Check_If_Contacts_Found Contacts Found? 0 0 No Contacts Contacts_Exist and Get_Related_Contacts IsNull false Update_Contacts_Bulk Contacts Exist Update_Contacts_Bulk Update Contacts (Bulk) 0 0 Log_Update_Error Industry varNewIndustry Get_Related_Contacts Log_Update_Error Log Update Error 0 0 Sub_LogError varErrorMessage $Flow.FaultMessage varFlowName Sub_UpdateContactIndustry varRecordId varAccountId 0 0 Get_Related_Contacts Draft varAccountId String true false varNewIndustry String true false ``` ### Child Flow 2: Sub_UpdateOpportunityStages ```xml 65.0 Updates Opportunity Stages based on Industry. Demonstrates conditional logic in child flows. Sub_UpdateOpportunityStages AutoLaunchedFlow Get_Related_Opportunities Get Related Opportunities 0 0 false Check_If_Opportunities_Found and AccountId EqualTo varAccountId IsClosed EqualTo false false

true Check_If_Opportunities_Found Opportunities Found? 0 0 No Opportunities Opportunities_Exist and Get_Related_Opportunities IsNull false Determine_Stage_By_Industry Opportunities Exist Determine_Stage_By_Industry Determine Stage By Industry 0 0 Set_Default_Stage Other Industries Technology_Industry and varIndustry EqualTo Technology Set_Technology_Stage Technology Healthcare_Industry and varIndustry EqualTo Healthcare Set_Healthcare_Stage Healthcare Set_Technology_Stage Set Technology Stage 0 0 varNewStage Assign Discovery Update_Opportunity_Stages Set_Healthcare_Stage Set Healthcare Stage 0 0 varNewStage Assign Needs Analysis Update_Opportunity_Stages Set_Default_Stage Set Default Stage 0 0 varNewStage Assign Qualification Update_Opportunity_Stages Update_Opportunity_Stages Update Opportunity Stages 0 0 Log_Update_Error StageName varNewStage Get_Related_Opportunities Log_Update_Error Log Update Error 0 0 Sub_LogError varErrorMessage $Flow.FaultMessage varFlowName Sub_UpdateOpportunityStages varRecordId varAccountId 0 0 Get_Related_Opportunities Draft varAccountId String true false varIndustry String true false varNewStage String false false ``` ## Benefits of This Pattern ### 1. **Modularity** Each child flow has one clear responsibility: - Sub_UpdateContactIndustry: Only handles Contact updates - Sub_UpdateOpportunityStages: Only handles Opportunity logic - Sub_SendEmailAlert: Only handles notifications ### 2. **Reusability** Child flows can be called from multiple parents: ``` RTF_Account_IndustryChange → Sub_UpdateContactIndustry RTF_Account_Merge → Sub_UpdateContactIndustry Auto_BulkIndustryUpdate → Sub_UpdateContactIndustry ``` ### 3. **Testability** Test each child independently: - Unit test: Sub_UpdateContactIndustry with 200 Contacts - Unit test: Sub_UpdateOpportunityStages with various Industries - Integration test: Parent flow with full scenario ### 4. **Maintainability** Update logic in one place: - Need to change Contact update logic? Edit Sub_UpdateContactIndustry - All parent flows automatically get the update - No need to find/replace across multiple flows ### 5. **Debugging** Clear error isolation: - Error in Contact update? Check Sub_UpdateContactIndustry logs - Parent flow shows which step failed - Error logs show exact subflow name ## Performance Considerations ### Governor Limits - **Subflow Depth**: Max 50 levels (parent → child → grandchild...) - **DML Statements**: Each child's DML counts toward 150 limit - **SOQL Queries**: Each child's query counts toward 100 limit ### Best Practices ✅ Keep parent flow lightweight (orchestration only) ✅ Put complex logic in children ✅ Use bulkified operations in each child ✅ Monitor total DML/SOQL across all children ## Testing Strategy ### 1. Unit Test Each Child ```bash # Test Sub_UpdateContactIndustry Create 200 test Contacts → Manually invoke flow → Verify all updated ``` ### 2. Integration Test Parent ```bash # Test full orchestration Update Account Industry → Verify all children executed → Check audit logs ``` ### 3. Bulk Test ```bash # Test with 200+ Accounts Data Loader update 200 Accounts → Verify no governor limit errors ``` ## When to Add More Children Add a new child subflow when: - New requirement emerges (e.g., "Also update Cases") - Existing child gets too complex (>200 lines) - You need to reuse logic elsewhere ```xml Update_Cases Update Related Cases 0 0 Notify_Owner Sub_UpdateCaseIndustry varAccountId $Record.Id varIndustry $Record.Industry ``` ## Related Patterns - [Sequential Orchestration](orchestration-sequential.md) - Chain flows A → B → C - [Conditional Orchestration](orchestration-conditional.md) - Parent decides which children to call - [Subflow Library](../references/subflow-library.md) - Reusable subflow templates ## Summary **Parent-Child orchestration** transforms complex automations from monolithic nightmares into modular, maintainable architectures. Each child flow is focused, testable, and reusable—making your entire automation ecosystem more robust. **Key Takeaway**: If your flow has more than 3 distinct responsibilities, consider breaking it into a parent orchestrator with child subflows. Your future self (and your team) will thank you! 🚀