Salesforce Flow: The Complete Guide to Declarative Automation

Salesforce Flow has gone from "the slow option" to "the default option" over the past four releases. As of Winter '23, Workflow Rules and Process Builder are deprecated for new builds — Flow is the path forward. This pillar links every Flow guide on the site, organized by the questions you'll actually have.

What is Salesforce Flow?

Salesforce Flow is the platform's declarative automation tool — a visual canvas where admins build business logic without writing Apex. It runs on the same multi-tenant runtime as Apex, respects the same governor limits, and integrates with every Salesforce object.

Since Winter '23, Flow officially replaces:

• Workflow Rules (use Record-Triggered Flow instead)
• Process Builder (same — Record-Triggered Flow)
• Approval Processes can still be standalone, but Flow is the modern alternative for new approval logic.

Lightning Web Components remain for UI, Apex remains for complex code, but for most "when X happens, do Y" patterns, Flow is now the right answer.

The four flow types

Type	Trigger	UI?	Common use
Screen Flow	User clicks a button or follows a guided link	Yes	Wizards, forms, guided record creation
Auto-Launched	Called from Apex, another flow, REST API	No	Reusable subroutines, integrations
Record-Triggered	A record is inserted, updated, or deleted	No	Replaces most workflow rules / process builders
Schedule-Triggered	A cron schedule	No	Nightly cleanup, batch updates

Most orgs use all four eventually. Pick by who/what triggers the work.

Record-Triggered Flow: the workhorse

This type replaces what Workflow Rules and Process Builder did. Two timing options:

Before-Save (Fast Field Update) — runs before the database save:

• Can ONLY modify fields on the same record being saved.
• ~10× faster than after-save (no second save cycle).
• Use for default values, normalization, calculated fields.

After-Save — runs after the database save:

• Can update related records, send emails, call Apex, invoke approval processes.
• Records have an Id (useful for inserts).
• Slower than before-save but supports cross-record actions.

The mental rule: same-record edits → before-save. Anything else → after-save.

Best practices

Bulkification, fault paths, and trigger choice are the three biggest determinants of whether your flows survive in production. The full list of 12 rules: Salesforce Flow Best Practices: 12 Rules That Prevent 90% of Errors.

The non-negotiables:

1. Never put a Get/Create/Update/Delete element inside a loop. Build collections, then operate on them once.
2. Always add a fault path to every DML element. Without one, failures are invisible to users.
3. Pick before-save vs after-save deliberately. Before for self-record edits, after for everything else.
4. Test with 200 records. A flow that works for one record can crash on a Data Loader job.

The Transform element (Spring '24+)

The Transform element changed how Salesforce thinks about collection mapping. Instead of writing a loop element that builds a new collection, you describe the input → output mapping declaratively:

Input collection: List of Cases
For each Case → output a CaseResult with {
  CaseId = case.Id,
  Subject = case.Subject + ' [PRIORITY]',
  AssignedTo = case.OwnerId
}

The runtime executes this in a single pass without manual loops. Fewer elements, fewer governor-limit risks, easier to reason about. See: Salesforce Flow Transform: Collections Without Loops.

For aggregate-style transformations (sum/count over a collection), see Salesforce Flow Transform Aggregations: Sum & Count.

Debugging Flows

Three tools, in order of usefulness:

1. Flow Builder's Debug button — runs the flow with test inputs and shows the value of every variable at every step. The single most-used debugging tool.
2. Process Automation Debug Logs — Setup → Process Automation → Process Automation Settings → enable. Captures full state on every flow run for selected users.
3. Setup → Apex Jobs — surprisingly, triggered flow exceptions show up here. For "the flow ran but did nothing" mysteries, this is where the answer hides.

For the deeper debugging playbook including silent-failure patterns, see the Flow best practices post linked above.

Order of execution

Flows fit into a specific spot in the save lifecycle:

1. Before triggers
2. Custom validation rules
3. Record commits to buffer
4. After triggers
5. Assignment / auto-response rules
6. Workflow field updates (legacy; can re-trigger steps 1-6 once)
7. Process Builder / Flow trigger automations
8. Roll-up summary recalcs
9. Sharing rules
10. DB commit
11. Post-commit (emails, async, Platform Events)

Note that trigger automations run after after-triggers. This is why a flow can't easily react to changes a trigger just made — the trigger fires, then the flow runs, but they're often racing for the same fields. The full reference: Salesforce Order of Execution.

Deep-dive guides

• Salesforce Flow Best Practices: 12 Rules That Prevent 90% of Errors
• Salesforce Flow Transform: Collections Without Loops
• Salesforce Flow Transform Aggregations: Sum & Count
• Salesforce Flow Bulkification
• Apex vs Flow: When to Use Code
• Salesforce Order of Execution
• How to Trigger a Record-Triggered Flow
• Screen Flow Business Logic: Advanced Workarounds
• Salesforce Flow Bulkification

Common Flow mistakes

• DML inside a loop. Same as Apex — build collections, operate once.
• Forgetting fault paths. Silent failures plus angry users.
• One mega-flow per object. Split by intent (validation vs notification) and trigger event (insert vs update).
• Skipping bulk testing. A flow that works for one record can crash on a 200-row import.
• Not picking before-save when it applies. The 10x performance difference adds up.
• Recursion via workflow re-triggers. Use the $Flow.CurrentRecord recursion guard or check stamp fields.

Salesforce Flow is one of the most leveraged tools an admin or developer can master in 2026. It's faster to build than Apex, easier to maintain, and now performant enough for serious production work. Pick the right type, follow bulkification rules, add fault paths, and your flows will outlast every other automation in the org.