# Sf Flow Automation

> Build and configure Salesforce Flows and automation including Record-Triggered Flows, Screen Flows, Scheduled Flows, Approval Processes, Platform Event-Triggered Flows, and Flow Orchestrator. Use this skill whenever the user mentions Salesforce Flow, Flow Builder, record-triggered flow, before-save flow, after-save flow, screen flow, approval process, scheduled flow, autolaunched flow, platform event flow, flow orchestrator, flow governor limits, flow bulkification, DML in loop, flow error handling, fault path, flow formula, invocable action, flow subflow, flow variable, flow collection, approval step, approval action, or any automation design on the Salesforce platform. Also trigger when the user asks about order of execution, flow best practices, flow deployment, flow testing, flow debugging, or migrating from Process Builder or Workflow Rules to Flow. Even if the user just says "automate this process" or "build a flow for this," use this skill.

- Skill: `andrewdhood/sf-flow-automation` (Agent Skill, multi-file: 31 files)
- Install (CLI): `npx skillmds@latest add andrewdhood/sf-flow-automation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/andrewdhood/sf-flow-automation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: andrewdhood (https://skillmd.com/u/andrewdhood)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/andrewdhood/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:

| Limit | Number | What Triggers It |
|---|---|---|
| SOQL queries | 100 | Each Get Records element = 1 query |
| DML statements | 150 | Each Create/Update/Delete Records = 1 DML |
| Records retrieved (SOQL) | 50,000 | Total across all Get Records |
| Records processed (DML) | 10,000 | Total across all Create/Update/Delete |
| Flow elements executed | 2,000 | Per flow interview (not per transaction) |
| CPU time | 10,000 ms | Sync; 60,000 ms async |
| Callouts | 100 | Per transaction |

**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:

| Topic | File |
|---|---|
| Record-Triggered Flows (before/after save, async) | `reference/record-triggered/record-triggered-flows.md` |
| Order of Execution | `reference/common-patterns/order-of-execution.md` |
| Governor Limits & Bulkification | `reference/common-patterns/governor-limits-and-bulkification.md` |
| Screen Flows | `reference/flow-builder/screen-flows.md` |
| Flow Elements & Resources Reference | `reference/flow-builder/elements-and-resources.md` |
| Flow Metadata XML Quick Reference | `reference/flow-builder/flow-metadata-reference.md` |
| Approval Processes | `reference/approval-processes/approval-processes.md` |
| Scheduled & Autolaunched Flows | `reference/scheduled-autolaunched/scheduled-and-autolaunched-flows.md` |
| Platform Event-Triggered Flows | `reference/platform-events/platform-event-flows.md` |
| Flow Orchestrator | `reference/orchestrator/flow-orchestrator.md` |
| Flow Security Model (run context, sharing) | `reference/common-patterns/flow-security-model.md` |
| Null Handling (null vs blank vs empty) | `reference/common-patterns/null-handling.md` |
| Flow Testing & Debugging | `reference/common-patterns/flow-testing.md` |
| Flow Deployment & Versioning | `reference/common-patterns/flow-deployment.md` |
| Common Pitfalls (top 25) | `reference/common-pitfalls.md` |

## Checklists

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

| Checklist | File |
|---|---|
| New Flow design & deployment | `checklists/new-flow-checklist.md` |
| Approval Process setup | `checklists/approval-process-checklist.md` |

## Templates

Use these as starting points when generating flow metadata:

| Pattern | Directory |
|---|---|
| Record-Triggered Flow (before-save + after-save) | `templates/record-triggered-flow/` |
| Screen Flow (record edit with input variable) | `templates/screen-flow/` |
| Scheduled Flow (daily batch update) | `templates/scheduled-flow/` |
| Platform Event-Triggered Flow | `templates/platform-event-flow/` |
| Approval Process (.approvalProcess-meta.xml) | `templates/approval-process/` |