Sf Flow Automation

Salesforce Flow & Automation Development

Design and build production-grade Salesforce Flows and automation with correct governor limit awareness, proper bulkification, appropriate trigger type selection, and robust error handling.

Before Designing Any Automation

1. Determine the automation type. Ask what triggers the automation if not specified:

   • Record change → Record-Triggered Flow (before-save, after-save, or async)
   • User interaction → Screen Flow
   • Time-based → Schedule-Triggered Flow or Scheduled Path on Record-Triggered Flow
   • External event → Platform Event-Triggered Flow
   • Multi-step process with human tasks → Flow Orchestrator
   • Approval workflow → Approval Process (or Flow Orchestrator for complex cases)

   Read reference/record-triggered/record-triggered-flows.md for record-triggered patterns or reference/flow-builder/screen-flows.md for screen flow patterns.

2. Determine before-save vs after-save (for record-triggered flows):

   • Before-save: Only modifying the triggering record's fields → no DML cost, fastest
   • After-save: Creating/updating related records, sending emails, calling external services
   • Run asynchronously: Heavy processing, callouts, operations that can be eventually consistent

   Read reference/record-triggered/record-triggered-flows.md for the decision matrix.

3. Check the order of execution to understand when your flow runs relative to validation rules, Apex triggers, and other automations: Read reference/common-patterns/order-of-execution.md.

4. Plan for bulk operations. Any flow triggered by data loads, imports, or Apex batch jobs processes up to 200 records per transaction. Design flows that work correctly for both single-record and bulk operations: Read reference/common-patterns/governor-limits-and-bulkification.md.

Record-Triggered Flow Quick Reference

Before-Save (fastest, no DML cost)

Use when: Modifying only the triggering record's fields
Runs: Before validation rules, before DML commit
DML cost: None (field assignments only)
Can do: Set field values on triggering record
Cannot do: Create/update/delete other records, send emails, call Apex

After-Save (most common)

Use when: Need to create/update related records, send notifications, call Apex
Runs: After DML commit of triggering record
DML cost: Normal (each Create/Update/Delete = 1 DML statement)
Can do: Everything — CRUD on any object, emails, invocable actions, subflows
Cannot do: Modify triggering record without additional DML (use before-save instead)

Run Asynchronously

Use when: Callouts, heavy processing, operations that don't need immediate consistency
Runs: In a separate transaction after the original transaction commits
DML cost: Separate governor limit context (fresh limits)
Can do: Callouts, long-running operations
Cannot do: Block the user's save operation

Governor Limits in Flow

These limits apply per transaction — know them before designing any flow:

The #1 Flow anti-pattern: DML inside a loop. If your flow loops over 200 records and each iteration has a Create Records element, that's 200 DML statements — over the 150 limit. Fix: Use collection variables to accumulate records, then do one Create Records element after the loop.

Read reference/common-patterns/governor-limits-and-bulkification.md for patterns.

Approval Processes

When building approval workflows:

1. Entry criteria determine which records enter the process — use formula for complex logic
2. Approval steps define who approves and in what order
3. Actions fire at specific stages: initial submission, approval, rejection, recall
4. Records are locked during approval by default
5. Trigger from Flow using the "Submit for Approval" core action

Read reference/approval-processes/approval-processes.md for the full setup guide.

Screen Flow Patterns

When building interactive flows:

1. Choose the right run context: user context (default) respects sharing; system context bypasses sharing (use carefully)
2. Use reactive screens for dynamic visibility and conditional components
3. Custom LWC screen components need the flow:availableForFlowScreens interface
4. Distribute via Lightning pages, quick actions, utility bar, or Experience Cloud

Read reference/flow-builder/screen-flows.md for patterns.

Error Handling

• Always add fault connectors on DML and callout elements
• Use the Custom Error element (Winter '24+) for user-friendly error messages in record-triggered flows
• Fault paths receive {!$Flow.FaultMessage} with the error detail
• Consider rollback behavior: after-save flow failures roll back the entire transaction

Flow Metadata & Deployment

• Flows are stored as .flow-meta.xml in force-app/main/default/flows/
• Only one version can be active at a time
• Deploy via sf project deploy start — include the flow metadata file
• Test flows in sandbox before activating in production
• Use Flow Test (Setup → Flow Test) for automated testing of autolaunched/record-triggered flows

Reference Docs

Read the relevant reference doc BEFORE designing automation:

Checklists

Offer relevant checklists when the user is building or deploying automations:

Templates

Use these as starting points when generating flow metadata: