The Complete 2026 Guide to Record-Triggered Flows in Salesforce

TL;DR

• Record-triggered flows fire when a record is created, updated, or deleted. They are the default automation in 2026, replacing Workflow Rules and Process Builder.
• Before-save runs in the same transaction before the record commits — best for setting field values on the record itself. Cheap and fast.
• After-save runs after commit — best for cross-record updates, sending email, calling sub-flows, kicking off async work.
• Scheduled paths delay actions to a future time — minutes, hours, or days after the trigger.

Workflow Rules and Process Builder are retired. Their successor, the record-triggered Flow, is the most-used automation primitive on the Salesforce platform in 2026. Knowing this primitive cold is the difference between an admin who ships and an admin who debugs all day.

This guide is the complete tutorial: when to pick before-save vs after-save, how to use entry conditions correctly, scheduled paths, the "Only when updated to meet criteria" gotcha that costs teams hours, and five worked examples you can rebuild in your own org.

Before-save vs after-save

The single biggest decision in record-triggered flow design.

Rule of thumb: if the only change is to the record itself, use before-save. Anything else, use after-save.

A common mistake is using after-save to set fields on the triggering record. That works — but it costs you a second DML on the same record, which is wasteful at scale. Promote it to before-save.

Entry conditions

Entry conditions decide whether the flow fires at all. They evaluate at the moment the trigger is checked.

Three modes:

1. Every time a record is created or updated — fires unconditionally. Use sparingly. Most flows shouldn't fire on every change.
2. Only when a record is updated to meet criteria — fires only when the record transitions into matching the criteria. The famous gotcha: if the record was already meeting criteria before the update, the flow does not fire. This is what trips up most admins.
3. A record is updated and meets criteria — fires on every update where the record currently meets criteria, regardless of whether it just transitioned in.

The difference between #2 and #3 is the source of more "why didn't my flow fire?" tickets than anything else. #2 = transition. #3 = current state. Pick deliberately.

Before update: Account.Type = 'Customer'
After update:  Account.Type = 'Customer' (no change)

Mode 2 ('updated to meet'): does NOT fire
Mode 3 ('meets criteria'):   DOES fire

If you need "fire when X becomes true and stays true", use mode 2 + mode 3 in two separate flows or build the transition logic explicitly.

Scheduled paths

A scheduled path delays after-save work to the future. Examples: send a follow-up email 3 days after a Case is closed; create a renewal task 30 days before subscription end; auto-close stale Opportunities after 90 days of inactivity.

Scheduled paths run in a separate, async transaction context, so they get higher governor limits (60s CPU, 12MB heap). They're charged against your async limits, not sync.

Important: scheduled paths can be canceled if the entry conditions change before they fire. A path scheduled for "3 days from Case Closed" will not fire if the Case is reopened in the interim.

Five worked examples

Build these in a Developer Edition org. Each takes 5–15 minutes.

Example 1: Auto-create a follow-up Task on Lead Conversion

Before-save mode would seem natural — but you're creating a different record (Task), so it's after-save.

• Object: Lead
• Trigger: A record is updated
• Mode: Only when updated to meet criteria
• Criteria: IsConverted = TRUE
• Action: Create a Task with subject "Follow up on converted Lead", due in 3 days, assigned to Lead Owner

Example 2: Email Alert on Case Escalation

• Object: Case
• Trigger: A record is updated
• Mode: Only when updated to meet criteria
• Criteria: Priority = 'High' AND IsEscalated = TRUE
• Action: Send Email Alert to the Case Team using a pre-built email template

Example 3: Parent-Child Update on Closed Won

When an Opportunity hits Closed Won, increment a custom counter on the parent Account.

• Object: Opportunity
• Trigger: A record is updated
• Mode: Only when updated to meet criteria
• Criteria: StageName = 'Closed Won'
• Action: Update Records (Account where Id = Opportunity.AccountId), set NumberOfWonOpps__c = NumberOfWonOpps__c + 1

⚠ Bulk caution: if a Subflow does this in a loop, you risk DML-statement-per-iteration. Use the Flow's collection-aware update pattern instead.

Example 4: Closed Won Workflow Suite

When an Opportunity reaches Closed Won, do five things in sequence:

1. Update Account Customer_Status__c = 'Active'
2. Create a project record (custom object)
3. Send a celebration email to the Sales Team
4. Schedule a 30-day check-in task
5. Post to a Slack channel via Apex-callout subflow

This is a single record-triggered flow with after-save mode + 1 scheduled path (for #4) + 1 subflow call (for #5).

Example 5: Queue Assignment for High-Value Opportunities

When a high-value Opportunity is created, route it to a Queue.

• Object: Opportunity
• Trigger: A record is created
• Mode: Every time a record is created
• Criteria: Amount > 100,000
• Action: Update Records (this Opportunity), set OwnerId = [HighValueQueueId]

This is a great before-save use case — you're setting OwnerId on the triggering record itself. No second DML.

Performance tips

• Bulkification. Even though you're "looking at one record" in Flow Builder, the runtime processes records in batches. Get Records and Update Records elements take collection variables — use them.
• Get Records once. Multiple Get Records on the same object in the same flow is almost always a sign you should refactor to one query with multiple filters.
• Decision elements before Get Records. If you don't need the data unless a condition is true, put the Decision first.
• Async paths for slow work. Anything that calls an external API, generates a PDF, or does heavy computation belongs in an async path or a Subflow that calls invocable Apex.

The migrate-to-Flow tool

Salesforce ships Migrate to Flow to convert old Workflow Rules and Process Builders. It works for ~70% of cases cleanly. The 30% that need manual help:

• Cross-object field updates with custom logic
• Workflow Rules with a custom field-update + outbound message combination
• Process Builders with conditional logic that doesn't translate 1:1 to Flow's branch model
• Anything calling an Apex Action that doesn't have a clean Flow equivalent

For the 30%, plan to rebuild manually rather than fight the converter. Then delete the originals — don't leave them disabled-but-present.

Common mistakes

• Mode 2 vs Mode 3 confusion. "Only when updated to meet criteria" fires on transition only. "Meets criteria" fires every update. Pick deliberately.
• Set fields in after-save. Wastes a DML. Move to before-save.
• DML inside a loop. Even Flow can do this. Use Update Records on a collection, not inside a loop.
• No test classes for Flow. Flow tests are optional but should be required practice for any production-bound Flow.
• Forgetting that Agentforce Actions can fire flows. If your flow has side effects, an agent can trigger them. Audit accordingly.
• Using Process Builder in 2026. It's retired. If you're still on it, run Migrate to Flow.

Frequently asked questions

Can I have multiple record-triggered flows on the same object? Yes — but you should consolidate. Salesforce evaluates flow order alphabetically and the order can affect outcomes. Best practice: one flow per object, organize internally with Subflows.

Will a record-triggered flow fire on a Bulk API insert? Yes. Flow fires for every record, regardless of source. Bulkify accordingly.

Can a record-triggered flow modify the running user's permissions? No. Flows run in the context of the running user (or a system context if Run As is configured). They can't bypass governor limits or Field-Level Security.

What's the difference between a Flow and a Subflow? A Subflow is just a Flow that's invoked from another Flow. It's the modular reuse pattern.

Should I use Apex instead? See our Flow vs Apex 2026 decision guide. The short version: Flow first, Apex when you need recursion, mid-transaction callouts, or precise CPU control.

What to read next

• Flow, Subflow, Migrate to Flow — the dictionary entries.
• Flow vs Apex 2026 — when to combine.
• Governor Limits 2026 — the limits Flow shares with Apex.

Build all five examples this week. The patterns only stick once your hands have done them.