# Orchestration Pattern: Conditional > The Conditional pattern uses a parent flow to evaluate conditions and dynamically decide which child subflows to execute. - Skill: `tools-only/orchestration-pattern-conditional` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add tools-only/orchestration-pattern-conditional` - Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/orchestration-pattern-conditional/raw - Safety review: pending (external: skill-scanner PASS, skillspector CAUTION) - 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-conditional --- # Orchestration Pattern: Conditional ## Overview The **Conditional pattern** uses a parent flow to evaluate conditions and dynamically decide which child subflows to execute. Think of it as a smart router that directs automation down different paths based on business rules. ## When to Use This Pattern ✅ **Use Conditional when:** - Different scenarios require completely different logic - You want to avoid complex branching in a single flow - Child flows can be developed by different teams - Business rules determine which automation to run - You need to add new scenarios without modifying existing logic ❌ **Don't use when:** - All steps must execute regardless of conditions - Logic is simple (use inline decisions instead) - Conditions are trivial (no need for separate subflows) ## Real-World Example: Case Triage and Routing ### Business Requirement When a Case is created, route it to the appropriate team and apply appropriate automation based on priority and type: - **Priority = Critical** → Escalate immediately, page on-call engineer, create Slack alert - **Priority = High + Type = Technical** → Assign to senior support, create Jira ticket - **Priority = High + Type = Billing** → Assign to billing team, check payment status - **Priority = Medium/Low** → Standard assignment, send email notification Each scenario has completely different logic, so we route to specialized subflows. ## Architecture ``` Parent: RTF_Case_TriageRouter (Decision Hub) ↓ ├── [Critical] → Sub_EscalateCriticalCase │ ├── Page on-call engineer │ ├── Create Slack alert │ └── Assign to escalation queue │ ├── [High + Technical] → Sub_HandleTechnicalCase │ ├── Assign to senior support │ ├── Create Jira ticket │ └── Set SLA timer │ ├── [High + Billing] → Sub_HandleBillingCase │ ├── Check payment status │ ├── Assign to billing team │ └── Generate payment report │ └── [Medium/Low] → Sub_HandleStandardCase ├── Auto-assign by round-robin └── Send email notification ``` ## Implementation ### Parent Flow: RTF_Case_TriageRouter ```xml 65.0 Conditional orchestrator that routes Cases to appropriate subflows based on priority and type. RTF_Case_TriageRouter BuilderType LightningFlowBuilder AutoLaunchedFlow Route_By_Priority_And_Type Route By Priority And Type 0 0 Handle_Standard_Case Standard (Medium/Low) Critical_Priority and $Record.Priority EqualTo Critical Escalate_Critical_Case Critical High_Priority_Technical and $Record.Priority EqualTo High $Record.Type EqualTo Technical Handle_Technical_Case High + Technical High_Priority_Billing and $Record.Priority EqualTo High $Record.Type EqualTo Billing Handle_Billing_Case High + Billing Escalate_Critical_Case Escalate Critical Case 0 0 Sub_EscalateCriticalCase varCaseId $Record.Id varCaseNumber $Record.CaseNumber varSubject $Record.Subject Handle_Technical_Case Handle Technical Case 0 0 Sub_HandleTechnicalCase varCaseId $Record.Id varCaseNumber $Record.CaseNumber varDescription $Record.Description Handle_Billing_Case Handle Billing Case 0 0 Sub_HandleBillingCase varCaseId $Record.Id varAccountId $Record.AccountId Handle_Standard_Case Handle Standard Case 0 0 Sub_HandleStandardCase varCaseId $Record.Id 0 0 Route_By_Priority_And_Type

Create RecordAfterSave Draft ``` ### Child Flow 1: Sub_EscalateCriticalCase ```xml 65.0 Handles critical case escalation with immediate notifications and special routing. Sub_EscalateCriticalCase AutoLaunchedFlow Page_On_Call_Engineer Page On-Call Engineer 0 0 PagerDuty_Trigger_Alert apex Create_Slack_Alert caseId varCaseId urgency high Create_Slack_Alert Create Slack Alert 0 0 Slack_Post_Message apex Assign_To_Escalation_Queue channel #critical-alerts message 🚨 CRITICAL CASE: {!varCaseNumber} - {!varSubject} Assign_To_Escalation_Queue Assign To Escalation Queue 0 0 Log_Assignment_Error and Id EqualTo varCaseId OwnerId 00G5e000001XYZ1 Status Escalated

Log_Assignment_Error Log Assignment Error 0 0 Sub_LogError varErrorMessage $Flow.FaultMessage varFlowName Sub_EscalateCriticalCase varRecordId varCaseId 0 0 Page_On_Call_Engineer Draft varCaseId String true false varCaseNumber String true false varSubject String true false ``` ### Child Flow 2: Sub_HandleTechnicalCase ```xml 65.0 Handles high-priority technical cases with Jira integration and senior support assignment. Sub_HandleTechnicalCase AutoLaunchedFlow Create_Jira_Ticket Create Jira Ticket 0 0 Jira_Create_Issue apex Get_Senior_Support_Agent summary SF Case {!varCaseNumber} description varDescription priority High true Get_Senior_Support_Agent Get Senior Support Agent 0 0 false Assign_To_Senior_Support and IsActive EqualTo true UserRole.Name EqualTo Senior Support Engineer true

NumberOfCasesAssigned__c Asc true Assign_To_Senior_Support Assign To Senior Support 0 0 and Id EqualTo varCaseId OwnerId Get_Senior_Support_Agent.Id Status In Progress Jira_Ticket_Id__c Create_Jira_Ticket.ticketId

0 0 Create_Jira_Ticket Draft varCaseId String true false varCaseNumber String true false varDescription String true false ``` ## Key Characteristics ### 1. **Single Decision Point** All routing logic centralized in one decision element in the parent flow ### 2. **Mutually Exclusive Paths** Only ONE child subflow executes per scenario: ``` If Critical → Sub_EscalateCriticalCase ONLY If High+Tech → Sub_HandleTechnicalCase ONLY If High+Billing → Sub_HandleBillingCase ONLY Else → Sub_HandleStandardCase ONLY ``` ### 3. **Specialized Children** Each child flow is optimized for its specific scenario with unique logic ### 4. **Easy to Extend** Add new scenarios by adding new rules and new child subflows: ```xml VIP_Customer $Record.Account.Type EqualTo VIP Handle_VIP_Case VIP Customer ``` ## Benefits of Conditional Pattern ### ✅ Separation of Concerns - Routing logic in parent - Business logic in children - No mixing of concerns ### ✅ Team Collaboration - Critical escalation team owns Sub_EscalateCriticalCase - Technical support team owns Sub_HandleTechnicalCase - Billing team owns Sub_HandleBillingCase - Teams work independently ### ✅ Simplified Testing - Test routing logic separately from business logic - Mock child subflows for parent testing - Test each child independently with representative data ### ✅ Performance Optimization - Only execute logic needed for the scenario - Avoid unnecessary queries and DML - Faster execution than "check everything" approach ### ✅ Maintainability - Add new scenarios without touching existing children - Modify specific scenario logic without affecting others - Clear separation makes debugging easier ## Common Use Cases 1. **Case Routing**: Route by priority, type, product, geography 2. **Lead Assignment**: Route by score, source, industry, region 3. **Approval Routing**: Route by amount, requestor, department 4. **Order Fulfillment**: Route by product type, shipping method, warehouse 5. **Error Handling**: Route by error type, severity, system ## Best Practices ### ✅ DO: 1. **Order Rules Carefully**: Most specific conditions first, default last 2. **Document Decision Logic**: Clear labels and descriptions 3. **Use Meaningful Names**: Sub_Handle{Scenario}Case, not Sub_Flow1 4. **Keep Parent Lightweight**: Only routing logic, no business logic 5. **Make Children Self-Contained**: Each child has everything it needs ### ❌ DON'T: 1. **Duplicate Logic Across Children**: Extract common logic to shared subflows 2. **Make Conditions Too Complex**: If routing is complex, simplify business rules 3. **Forget the Default Path**: Always have a fallback scenario 4. **Mix Routing and Business Logic**: Keep parent as pure router 5. **Create Too Many Paths**: >10 paths suggests need for different pattern ## Advanced Pattern: Dynamic Routing For scenarios where routing rules are stored as metadata: ```xml Get_Routing_Rules Get Routing Rules

IsActive__c EqualTo true Priority__c Asc true Evaluate_Routing_Rules Get_Routing_Rules Asc ``` ## Performance Considerations ### Governor Limits - **DML Statements**: Only the executed child's DML counts (not all children) - **SOQL Queries**: Only the executed child's queries count - **Execution Time**: Faster than sequential (no unnecessary steps) ### Optimization Tips 1. Order decision rules by frequency (most common first) 2. Use indexed fields in routing conditions 3. Keep routing decision fast (<100ms) 4. Profile which paths execute most often ## Error Handling Each child should handle its own errors: ```xml Some_Operation Log_Child_Error Log_Child_Error Sub_LogError varFlowName Sub_HandleTechnicalCase ``` ## Related Patterns - [Parent-Child Orchestration](orchestration-parent-child.md) - Execute all children - [Sequential Orchestration](orchestration-sequential.md) - Chain flows in order - [Subflow Library](../docs/subflow-library.md) - Reusable components ## Summary **Conditional orchestration** enables smart routing where a parent flow evaluates business rules and directs execution to specialized child subflows. This pattern creates maintainable, testable automation where teams can own their scenarios independently. **Key Takeaway**: If your flow has complex branching with statements like "If critical, do X, Y, Z; if high-priority technical, do A, B, C," use conditional orchestration. Each scenario becomes a focused, testable subflow. 🎯