Flow Trigger
A Flow Trigger is the event that starts a Salesforce flow and sets the rules the flow runs under.
Definition
A Flow Trigger is the event that starts a Salesforce flow and sets the rules the flow runs under. Salesforce supports several trigger types: record-triggered (a create, update, or delete on a chosen object), screen (a user launching an interactive flow), schedule-triggered (a time-based recurrence), platform event-triggered (a published platform event message), and autolaunched (a call from Apex, the REST API, or a parent flow). You pick the trigger when you create the flow, and that choice shapes which elements appear, when the flow runs, and which limits apply.
The trigger also decides whether the flow runs inside the original transaction, after it, or on a separate async context. A record-triggered flow set to before-save runs during the save itself. The same flow set to after-save runs in a later phase, after validation. Choosing the wrong trigger combination is one of the most common reasons a new flow does not behave the way an admin expects.
How each trigger type changes the way a flow runs
Record-triggered: before-save versus after-save
Record-triggered flows fire on a create, update, or delete event on one object. The before-save variant runs inside the save transaction, sees the incoming field values, and writes back to the same record without a separate DML statement. That makes it fast and cheap on limits, but its element catalog is trimmed. You cannot call Apex actions, update related records, or send emails from a before-save flow. The after-save variant runs after the initial save and after standard validation. It has the full element catalog, so it can create and update related records, send notifications, and invoke Apex. A simple rule covers most cases. Use before-save when the only change is on the same record that triggered the flow, such as defaulting a field or normalizing data. Use after-save for anything that touches other records or external systems. Both variants support a trigger order value from 1 to 2000, which lets you control the sequence when several flows share the same object and the same trigger event. Flows with the same order value then run alphabetically by API name.
Screen triggers and running user context
A screen flow starts when a person interacts with it. That could be a click on a Flow component placed on a Lightning page, a quick action, a custom button or link, or a direct URL. Because a user launches it, the flow runs in that user session and respects their profile and permission sets. Sharing behavior depends on the run context you set, which can follow the running user or use system mode. Screen flows are the only trigger type that supports Screen elements, the building blocks that display fields, collect input, and walk someone through a guided set of steps. This matters when you change a flow from one type to another. If you switch the trigger away from Screen, Flow Builder removes every screen on the canvas because they are no longer valid. Screen flows are well suited to data entry wizards, guided service scripts, and any task where a person needs to see and confirm information mid-process. They do not run on their own, so a record change or a schedule cannot start one. You always need a person or a place in the UI that surfaces the flow.
Schedule-triggered flows for batch work
A schedule-triggered flow runs at a start time and frequency you set in Setup, such as once, daily, or weekly. You give it an object and an optional filter, and the flow queries the matching records, then processes each one in its own flow run. This is the modern replacement for many of the recurring Apex batch jobs that admins used to write for record sweeps, data hygiene, reminder emails, or end-of-day reconciliation. A key detail catches people out. Schedule-triggered flows run as the Automated Process user, not as you, so you must confirm that user can see and edit the records and fields the flow touches. The flow runs asynchronously and is not part of any user transaction, which means it does not block the UI and is governed by async limits. Because each scheduled run can process a large batch, you should keep per-record logic lean and avoid calls that do not bulkify well. When the volume of matching records grows over time, test against a realistic data set so the run finishes inside its limits.
Platform event-triggered flows for pub-sub
A platform event-triggered flow subscribes to a platform event and runs when a message on that event is published. This is the flow side of an event-driven design. Common patterns include reacting to a signal from an external system, handling device or IoT messages, and decoupling work inside the org so the publisher does not need to know who is listening. The flow runs once per event message it receives. Throughput is the thing to plan for. If a process publishes thousands of messages a minute, each one starts a separate flow run, and the usual per-transaction limits still apply to each run. Design the subscriber to do a focused unit of work and to fail gracefully, because a platform event consumer that errors can be retried. These flows run in system context as the Automated Process user, so sharing and field-level checks behave differently than a screen flow that runs as a person. Use platform event triggers when you want loose coupling and asynchronous handling rather than a synchronous record-triggered response inside the same save.
Autolaunched flows as reusable building blocks
An autolaunched flow has no trigger built into it. It runs only when something calls it: Apex code, the REST API, a custom button or link, a Visualforce page, or another flow that invokes it as a subflow. It supports the full element palette except Screen elements, since no user is present to see a screen. Think of an autolaunched flow as a function in code, factored out so logic can be reused in more than one place. This is the only clean way to share the same logic between a record-triggered flow and a screen flow. You build the shared steps once as an autolaunched flow, then call it as a subflow from each parent. That keeps a single copy of the rules instead of two drifting versions. Because they run without a UI, autolaunched flows fit well behind a button that kicks off a background action, inside a larger orchestration, or as a callable service that Apex hands work to. When you design one for reuse, give it clear input and output variables and a descriptive API name so callers know what it expects and returns.
Entry conditions and the order of execution
Trigger types that run on data, meaning record-triggered and schedule-triggered, support entry conditions. An entry condition is a filter checked before any element runs, so a record that does not match never starts the flow at all. This is cheaper than checking the same criteria inside an opening Decision element, because it short-circuits the whole flow and keeps CPU, SOQL, and DML counts down. Push filtering up to the trigger level whenever you can. Where each trigger lands in the Salesforce order of execution also matters. Before-save record-triggered flows run early in the save, after old-style workflow field updates have been evaluated but before the record is committed, so their same-record writes happen without extra DML. After-save flows run later in the order, after the record is saved and after other after-save automation. Knowing this sequence helps when a validation rule could block a value a later flow tries to set, or when two automations on the same object need a predictable order. Combined with the 1 to 2000 trigger order value, it gives you fine control over how stacked automations interact.
How to set the trigger on a new flow
You set the trigger when you create a new flow in Flow Builder. The first screen asks what should start the flow, and your answer locks in the trigger type and the elements you can use. Here is the path for a record-triggered flow, the most common automation choice.
- Open Flow Builder and create a flow
In Setup, go to Flow under Process Automation and click New Flow. Flow Builder opens the template chooser, which lists the trigger types you can start from.
- Pick the trigger type
Select Record-Triggered Flow for a DML-based automation, or pick Screen Flow, Schedule-Triggered Flow, Platform Event-Triggered Flow, or Autolaunched Flow for the other patterns. This choice is hard to undo, so confirm it before drawing elements.
- Choose the object and the trigger event
For a record-triggered flow, select the object, then choose whether the flow runs on create, on update, on create or update, or on delete. This is the DML event that fires the flow.
- Set entry conditions and the run timing
Add entry conditions so only matching records start the flow. Then choose Fast Field Update to run before save, or Actions and Related Records to run after save. Set the optional trigger order value if other flows share the object.
- Build, save, and activate
Add your elements, save the flow with a clear name, then activate it. An inactive flow will not run on the trigger even after you save it.
Runs on a create, update, or delete on one object. Offers before-save (Fast Field Update) and after-save timing.
Runs when a user launches it from a button, action, page, or URL. The only type that allows Screen elements.
Runs on a set schedule against a batch of records, as the Automated Process user, in async context.
Runs once per published platform event message, for event-driven and decoupled designs.
Runs only when called by Apex, the REST API, a button, or a parent flow as a subflow. No screens allowed.
- The trigger type is locked at the first save. Switching it later forces Flow Builder to drop elements that the new type does not support.
- Before-save flows cannot call Apex actions, update related records, or send emails. Use after-save for any of those.
- Schedule-triggered and platform event-triggered flows run as the Automated Process user, so check that user has access to every object and field the flow touches.
- Saving a flow is not enough. It must be activated before it will run on its trigger.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Flow Trigger.
- Triggers for Autolaunched and Triggered FlowsSalesforce
- Schedule-Triggered FlowsSalesforce
Hands-on resources to go deeper on Flow Trigger.
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…