Flow Trigger
A Flow Trigger is the event that starts a flow.
Definition
A Flow Trigger is the event that starts a flow. Salesforce supports five trigger types: record-triggered (a DML event on a chosen object), screen (a user launching the flow), schedule-triggered (a cron-like recurrence), platform event-triggered (a published platform event), and autolaunched (a call from Apex, REST, or another flow). The trigger is chosen at flow creation time and shapes which elements are available, how the flow runs, and which governor limits apply.
The trigger also dictates whether the flow runs in the same transaction as the original action, in a future async context, or on a queue. A record-triggered flow with a before-save trigger executes inside the save itself; the same flow set to after-save runs in a separate phase after validation. Picking the wrong trigger combination is the most common reason a brand-new flow does not behave the way an admin expects.
Picking the right trigger for the work
Record-triggered flows, before-save vs. after-save
Record-triggered flows fire on DML events on a single object. The before-save variant runs inside the save transaction, sees the incoming record values, and writes back to the same record without a separate DML statement. It has a stripped-down element catalog (no Apex actions, no related-record updates) but it is fast. The after-save variant runs after the initial save and after validation, has the full element catalog, and can update related records, send emails, and call Apex. Use before-save when the change is on the same record and after-save for everything else.
Screen triggers and user context
Screen flow triggers begin when a user clicks a Flow Lightning component, opens a quick action, or hits a URL. The flow runs in the user's session, with their profile, sharing, and permissions. The flow can produce screens that step through inputs, decisions, and confirmations. Screen flows are the only trigger type that supports Screen elements; switching trigger types away from Screen disables every screen on the canvas.
Schedule-triggered flows
Schedule-triggered flows run at a chosen start time and recurrence (once, daily, weekly). They query a batch of records that match a filter and process each one in a separate flow context. They replace the recurring Apex batch jobs that admins used to write for record sweeps, reporting, or end-of-day reconciliation. Schedule-triggered flows are async, do not run in any user transaction, and execute as the Automated Process user unless configured otherwise.
Platform event-triggered flows
Platform event-triggered flows subscribe to a platform event and run when one is published. Common patterns include cross-org notifications, IoT event handling, and decoupled internal pub-sub. The flow runs once per event message. Heavy throughput (thousands of events per minute) demands careful design because each event creates a new flow interview, and bulk limits still apply.
Autolaunched flows as building blocks
Autolaunched flows have no built-in trigger of their own. They run when called by Apex, REST API, a parent flow as a subflow, or a Process Builder process. They support the full element palette except Screen elements. Autolaunched flows are the equivalent of utility functions in code, factored out for reuse.
Entry conditions vs. inside-flow filters
Every trigger type that runs on data (record-triggered, schedule-triggered) supports entry conditions: a filter formula evaluated before any element executes. Entry conditions are far cheaper than checking the same criteria inside a Decision element, because they short-circuit the entire flow when the record does not match. Always push filtering up to the trigger level.
Order of execution and trigger placement
Record-triggered flows participate in the Salesforce order of execution. Before-save flows run after old-style Workflow Rules but before standard validation. After-save flows run after Workflow Rule field updates and after Process Builder. Knowing where each trigger lands in the order matters when a validation rule could block a downstream flow update.
Choose a trigger when creating a flow
Trigger selection is the first decision in Flow Builder. The screen that appears on New Flow lists every option with a short description.
- Identify the start event
Ask what triggers this work. A record save? A user clicking something? A timer? An external event? An Apex call? The answer maps directly to one trigger type.
- Pick the trigger in New Flow
Open Flow Builder, click New Flow. The dialog shows tiles for every trigger type. Pick one to load the corresponding canvas template.
- Configure trigger settings
Record-triggered flows ask for the object, the trigger event (created, updated, deleted, undeleted, created or updated), and whether to run before or after save. Schedule-triggered flows ask for the object filter and the recurrence.
- Set the entry condition
For data-driven triggers, set the entry-condition formula. This is the gate that decides whether the flow body runs at all.
- Save, debug, activate
Save with a descriptive label, run Debug with sample inputs, and activate the version once it behaves correctly.
- Switching the trigger type after building the flow body deletes any incompatible elements (Screen elements when switching away from Screen, async actions when switching to before-save). Pick the trigger first.
- Before-save flows cannot call Apex actions, send emails, or hit external systems. The simplified palette is a feature, not a limit to work around with another flow.
- Schedule-triggered flows run as the Automated Process user. Record-access checks evaluate against that user's profile, not the original record owner's.
- Platform event triggers fire once per event message. Bulk publishing can hit per-transaction limits inside the subscriber flow. Bulkify the body element-by-element.
Trust & references
Cross-checked against the following references.
- Flow Trigger TypesSalesforce Help
- Build a Record-Triggered FlowSalesforce Help
Straight from the source - Salesforce's reference material on Flow Trigger.
- Order of ExecutionSalesforce Developers
- How a Flow RunsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Flow Trigger?
Q2. What's the difference between before-save and after-save triggers?
Q3. What do entry conditions do?
Discussion
Loading discussion…