sf-agent-framework

# Flow Builder Task This task guides the creation and documentation of Salesforce Flows using best practices and proper architectural patterns. ## Purpose Enable administrators and developers to: - Design efficient, scalable Flows - Follow Salesforce best practices - Document Flow logic clearly - Avoid common pitfalls - Optimize for performance ## Flow Types Supported ### 1. Screen Flow - User interaction required - Multi-step wizards - Data collection forms - Guided processes ### 2. Record-Triggered Flow - Replaces Workflow Rules and Process Builder - Before/After Insert/Update/Delete - Scheduled paths for time-based actions ### 3. Scheduled Flow - Batch processing - Regular maintenance tasks - Data cleanup operations - Report generation ### 4. Platform Event-Triggered Flow - Real-time integrations - Asynchronous processing - Event-driven architecture ### 5. Autolaunched Flow - Called by other automation - Subflows for reusability - Complex business logic ## Design Process ### Step 1: Requirements Analysis ``` 1. Define business objective 2. Identify trigger/entry criteria 3. Determine data requirements 4. Map decision points 5. Plan error handling ``` ### Step 2: Flow Architecture ``` 1. Choose appropriate Flow type 2. Design entry criteria 3. Map data flow 4. Plan fault paths 5. Consider governor limits ``` ### Step 3: Best Practices Implementation **One Flow Per Object Pattern** ``` Object: Opportunity Flow: Opportunity Management Flow - Consolidates all automation - Reduces maintenance - Improves performance - Easier troubleshooting ``` **Naming Conventions** ``` Screen Flow: [Object]_[Process]_Screen_Flow Record-Triggered: [Object]_[Trigger]_RT_Flow Scheduled: [Object]_[Schedule]_Scheduled_Flow Autolaunched: [Object]_[Process]_Subflow ``` **Variable Naming** ``` - recordNew: New version of record - recordOld: Prior version of record - var_[Name]: Variables - col_[Name]: Collections - const_[Name]: Constants ``` ### Step 4: Performance Optimization **Query Optimization** - Use filters to limit records - Get Records only when needed - Store in variables for reuse - Avoid queries in loops **DML Optimization** - Collect updates in variables - Single DML at Flow end - Use Fast Field Updates - Avoid DML in loops **Loop Best Practices** - Process collections, not queries - Minimize operations in loops - Use collection variables - Consider batch processing ### Step 5: Error Handling **Fault Paths** ``` 1. Add fault connectors 2. Capture error details 3. Send notifications 4. Log errors 5. Graceful recovery ``` **Validation** - Check for null values - Validate user inputs - Confirm data integrity - Handle edge cases ## Common Patterns ### Pattern 1: Before-Save Updates ```yaml Trigger: Before Insert/Update Use Cases: - Field defaulting - Validation - Field calculations Benefits: - No additional DML - Better performance ``` ### Pattern 2: After-Save Actions ```yaml Trigger: After Insert/Update Use Cases: - Related record updates - Integrations - Notifications Considerations: - Separate DML required - Watch governor limits ``` ### Pattern 3: Decision Framework ```yaml Structure: 1. Evaluate most likely path first 2. Order by frequency 3. Default outcome last 4. Clear naming Example: - Is New Customer? (80% true) - Is Existing Customer? (15% true) - Default (5%) ``` ### Pattern 4: Subflow Usage ```yaml When to Use: - Repeated logic - Complex calculations - Modular design - Cross-object processes Benefits: - Reusability - Easier maintenance - Cleaner main Flow ``` ## Documentation Requirements ### Flow Description ```markdown **Flow Name**: [Name] **Type**: [Screen/Record-Triggered/etc] **Object**: [Primary object] **Purpose**: [Business objective] **Entry Criteria**: - [Condition 1] - [Condition 2] **Key Logic**: 1. [Step 1 description] 2. [Step 2 description] **Outputs**: - [What the Flow produces/updates] **Error Handling**: - [How errors are handled] ``` ### Element Documentation - Each element should have description - Complex formulas need comments - Decision criteria clearly stated - Integration points documented ## Testing Guidelines ### Test Scenarios 1. **Positive Path**: Expected behavior 2. **Negative Path**: Error conditions 3. **Bulk Testing**: Multiple records 4. **Permission Testing**: Different users 5. **Edge Cases**: Boundary conditions ### Debug Mode - Use Debug to test - Check variable values - Verify decision paths - Monitor resource usage ## Migration Considerations ### From Process Builder ``` 1. Identify all Process Builder processes 2. Consolidate into single Flow 3. Test entry criteria carefully 4. Migrate scheduled actions 5. Deactivate Process Builder ``` ### From Workflow Rules ``` 1. Map field updates 2. Convert email alerts 3. Recreate tasks 4. Handle time-based actions 5. Test thoroughly ``` ## Governor Limit Awareness ### Key Limits to Monitor - SOQL queries: 100 - DML statements: 150 - CPU time: 10,000ms - Heap size: 6MB - Collection size: 10,000 ### Optimization Strategies - Minimize queries - Bulk operations - Efficient loops - Async processing for heavy operations ## Success Criteria ✅ Flow achieves business objective ✅ Follows naming conventions ✅ Properly documented ✅ Error handling implemented ✅ Tested with bulk data ✅ Governor limits respected ✅ Maintainable design ## Common Pitfalls to Avoid ❌ Multiple Flows on same object/event ❌ Queries inside loops ❌ Hardcoded IDs ❌ Missing error handling ❌ No null checks ❌ Insufficient testing ❌ Poor documentation ## Integration Points - Can call Apex via Invocable Methods - Can trigger Platform Events - Can make HTTP callouts - Can integrate with External Services - Can update multiple objects ## Maintenance Tips 1. **Version Control**: Document changes 2. **Regular Reviews**: Check for optimization 3. **Monitor Performance**: Use debug logs 4. **Update Documentation**: Keep current 5. **Test After Updates**: Regression testing