Salesforce Flow: the 2025 basics (for busy Admins)

If you’re new to Salesforce Flow—or you’ve built a few and want a clean mental model—this primer gives you the essentials: where Flow fits, which type to choose, how to design safely at scale, and a quick start you can follow in 15 minutes.

What is Salesforce Flow (in one line)?

Flow is Salesforce’s click-based automation engine for updating data, guiding users with screens, and integrating with other systems—without writing Apex. It replaced most use cases for Workflow Rules and Process Builder.

When to use Flow vs. Apex

Use Flow when:

You’re automating straightforward create/update logic on a single object (or a couple of related ones).
You’re guiding a user through a form or process (Screen Flow).
You can work within Salesforce’s governor limits with collections and bulk-safe patterns.

Reach for Apex when:

Logic is complex, highly recursive, or must run across large datasets and tight limits.
You need fine-grained error handling, complex calculations, or advanced integrations.
You need reusable services shared by many automations.

Practical rule: if you can describe the logic as a simple “when X, do Y (and maybe Z)” and your data volumes are moderate, Flow is probably right.

Flow types (pick the right one)

Record-Triggered Flow: Fires when a record is created, updated, or deleted.
- Before-save (fast): Great for setting field values on the same record.
- After-save (powerful): For related updates, emails, callouts (via invocable actions), Platform Events, etc.
Screen Flow: Guided UI for users (wizards, intake forms, approvals with context).
Scheduled Flow: Runs on a schedule to process a set of records.
Autolaunched Flow: Runs behind the scenes—called by buttons, subflows, Apex, etc.

The essential building blocks

Get Records: Pull data once, filter narrowly, and store in collections when you expect many.
Assignment: Set variables, prepare collections.
Decision: Branch based on conditions (keep them simple and named clearly).
Loop: Iterate through a collection (never DML inside the loop).
Create/Update/Delete Records: Perform DML (prefer one operation per collection after a loop).
Subflow: Reuse logic across multiple flows.
Fault Paths: Always wire them. Send an internal alert with the error message.

Naming & structure that scales

One record-triggered flow per object per context: one for before-save, one for after-save. Use Subflows inside for modularity.
Name like a human would search: RTF_Account_BeforeSetDefaults or Subflow_Case_SetSLA.
Comments: Use the Flow Description and element descriptions. Your future self will thank you.

15-minute quick start: auto-set Case Severity

Goal: When a Case is created or updated, set Severity based on Impact and Urgency (fields on Case). Do it bulk-safe and easy to read.

Create a Record-Triggered Flow
- Object: Case
- Trigger: A record is created or updated
- Before-save (fast)
- Entry condition: IsClosed = false (optional, but tight filters help)
Decision: “Has Impact/Urgency?”
- Outcome Has Both: ISBLANK({!$Record.Impact__c}) = false and ISBLANK({!$Record.Urgency__c}) = false
- Default: Do nothing (safest)
Assignment (under Has Both)
- Create a Text resource varSeverity
- Use simple logic (two Decisions works too, but keep it clear):
  - If Impact = High and Urgency = High → varSeverity = "Critical"
  - Else if either is High → varSeverity = "High"
  - Else if both Medium → varSeverity = "Medium"
  - Else → varSeverity = "Low"
Update Records (this record)
- Set Severity__c = {!varSeverity}
Fault Path from the Update
- Send an email/Chatter/Slack/Teams alert to admins with {!$Flow.FaultMessage} (use your org’s preferred action)
Save & Activate
- Name: RTF_Case_BeforeSetSeverity
- Description: “Sets Severity from Impact/Urgency. Bulk-safe, before-save.”

Why before-save? It’s faster and doesn’t consume as many limits since it updates the record before the database write.

Common mistakes (and how to avoid them)

DML inside a loop → Collect records during the loop, then one Update outside.
Too many Gets → Get once, reuse the results (store in variables/collections).
Missing entry criteria → Add precise conditions to cut needless runs.
No fault handling → Always wire Fault paths and notify a human.
Spaghetti decisions → Keep branches short; push complicated logic to a subflow or formula field.

Testing your Flow (fast checklist)

Create at least 4 test records to cover each branch (Critical/High/Medium/Low in the example).
Use the Debug tool with Run As and sample records.
Test bulk behavior: update 200 records via Data Loader or a report inline edit.
Confirm no recursion: ensure your Flow doesn’t re-trigger itself endlessly. Use entry criteria like “field changed” checks where appropriate.

Deployment & change control

Build in a sandbox.
Use change sets or your DevOps tool to deploy.
Version your Flow; don’t delete old versions until you’ve monitored logs.
Announce the change—especially for Screen Flows that alter user experience.

Reusable patterns you’ll use often

Owner rules: Set default owner by region or product via a Custom Metadata lookup (Get → Decision → Assign).
SLA timers: Set target dates based on priority (Assignment + Update).
Related rollups (simple): After-save Flow + Get child records → Loop → Sum → Update parent.
Auto-archive: Scheduled Flow each night to set a flag when records meet criteria.

Performance tips (so your users don’t feel it)

Prefer Before-save for same-record field updates.
Use collections and one DML outside loops.
Narrow Get Records with indexed fields where possible.
Avoid unnecessary subflow calls in hot paths; reuse wisely.

Accessibility & UX (for Screen Flows)

Use section components and helpful help text.
Keep screens short; 1–3 questions per step.
Provide clear error messages and default values.
Test with keyboard-only navigation.

Where to go next

Try refactoring one older Process Builder into a single record-triggered flow per object.
Build a small Screen Flow for a support intake form with conditional questions.
Add fault alerts to your existing flows.

If you’d like a sanity check, we offer a light-touch Flow Health Check and a short, beginner-friendly Flow Fundamentals mini-course—designed for admins who prefer clear patterns over trial-and-error. Both are built to be practical and vendor-agnostic. (You can find them on our Services and Courses pages.)

TL;DR checklist

Choose the right type (Before vs After vs Screen)
One record-triggered flow per object/context
Tight entry criteria
No DML in loops; use collections
Fault paths wired with alerts
Tested with multiple scenarios and bulk updates