Salesforce Flow is not one trigger with several labels. Different Flow types start in different ways, run at different points in a transaction, and support different kinds of work. Choosing the trigger first is therefore an architecture decision: it determines what data is available, whether a user is waiting, whether the triggering record has already been committed, and whether the automation should respond to a record, a schedule, an event, or an explicit caller.
For the Salesforce Platform Administrator, the most important distinction is between interactive Screen Flows and autolaunched flows, then among the autolaunched triggers. Record-triggered flows are especially important because before-save and after-save execution look similar in Flow Builder but solve different problems.
Start with the event that should own the automation
A good Flow design begins with one question: what business event makes this work necessary? If a user must answer questions or make choices, a Screen Flow may be appropriate. If a record change should trigger background automation, use a record-triggered flow. If the work should run at a regular time across a set of records, use a schedule-triggered flow. If another automation, API, Apex process, subflow, or button should call the logic explicitly, a no-trigger autolaunched flow can provide reusable background behavior.
There are also event-driven forms such as platform event-triggered flows. These respond to messages rather than ordinary record CRUD. They are valuable when producers and consumers should be decoupled or when the event itself is the business signal.
Do not choose a trigger simply because it is familiar. A scheduled flow that polls every night for a condition that is already known at record update time may add unnecessary delay. A record-triggered flow used for a user interview forces background automation to solve an interactive problem it was not designed for.
Before-save record-triggered flows are optimized for the triggering record
A before-save record-triggered flow runs before Salesforce commits the triggering record. Current Salesforce guidance describes these as Fast Field Updates. They are designed for situations where the primary job is to set, normalize, or validate values on the record that caused the automation.
Examples include deriving a classification field, normalizing a text value, setting a date from another field, applying a default based on record state, or blocking a save when a supported error condition is detected. Because the record is already in the transaction, Salesforce can update the pending record without requiring a second save operation.
That makes before-save flows a strong default when all required changes stay on the triggering record. Do not use an after-save flow just because “after save” sounds safer if the only job is to update fields on the record being saved. The extra database work can be unnecessary.
After-save flows handle related records and downstream actions
An after-save record-triggered flow runs after the triggering record has been saved. Salesforce labels this path Actions and Related Records because it is the right place for work that depends on a committed record or needs to affect other records and systems.
Typical uses include creating a follow-up Task, updating related records, sending an email, invoking other automation, or performing actions that require the saved record identifier. If an Opportunity becomes Closed Won and the business must create onboarding records, notify operations, and update a related Account, after-save behavior fits the outcome.
After-save does not mean “put every complex flow here.” Entry conditions still matter. A flow should run only when the state change relevant to the business outcome occurs. If the flow runs on every edit and then uses a large Decision tree to discover that nothing is needed, it wastes transaction resources and makes recursion harder to reason about.
Before-delete flows protect the moment before a record is removed. Salesforce also supports record-triggered flows that run before a record is deleted. These are useful when the automation must inspect or act on the record while its values are still available in the delete transaction. The design questions are different from create/update flows because the record is leaving the system rather than moving to a new state.
Use delete-triggered automation carefully. A delete may occur from a user action, a bulk operation, an integration, or other process. The flow should be bulk-safe and should not assume a human is waiting for an interactive response. If the business requirement is to preserve history, consider whether archival, soft-deletion patterns, or business policy should prevent deletion rather than trying to reconstruct context afterward.
Schedule-triggered flows run work based on time, not a record event
A schedule-triggered flow launches at a specified time and frequency and processes records that meet the configured criteria. This is useful for aging, reminders, periodic synchronization, recurring compliance checks, or other work whose trigger is the passage of time.
For example, an organization may need to flag contracts approaching expiration, create follow-up tasks for stale opportunities, or review records whose status has not changed for a defined period. The record did not necessarily change at the moment the automation should run, so a record-triggered flow would not naturally own the requirement.
Scheduled automation should still have selective criteria. A nightly flow that scans a large object and makes no changes to almost every record is a design smell. Filter the population so the batch represents work that may actually need action.
Screen Flows are interactive experiences
A Screen Flow is different because a person participates in the flow. Screens can collect input, present information, guide a user through a process, and branch based on answers. The flow can be launched from supported surfaces such as pages, actions, portals, or other distribution methods.
Use Screen Flow when the business process needs a guided conversation rather than an automatic reaction. A support intake wizard, quote configuration assistant, or multi-step data collection experience can use screens to prevent users from facing one enormous form.
Keep the distinction between interaction and automation clear. A Screen Flow can call background logic, but reusable business behavior should not be trapped inside a screen-specific path if other automations need it. Extract reusable operations into subflows or invocable capabilities where appropriate.
Autolaunched flows without a trigger are reusable building blocks
A no-trigger autolaunched flow does not start itself because a record changed or a schedule arrived. Another process invokes it. This makes it useful for reusable background logic that should have a defined input/output contract.
For example, several record-triggered flows may need the same customer-risk calculation. Instead of copying the same elements into each flow, an autolaunched subflow can own the logic and be called from multiple automation paths. That reduces duplication and gives administrators one place to update the shared behavior.
Reusable flows should be designed like APIs: clear input variables, predictable output, documented side effects, and sensible fault paths. If a subflow silently assumes it is always called from one particular object state, reuse will eventually expose the hidden assumption.
Platform event-triggered flows respond to published events. A platform event-triggered flow starts when the specified platform event message is received. This model is useful when systems or processes publish that something happened and consumers should react without being tightly coupled to the producer’s database transaction.
Event-driven design can improve separation between systems, but it introduces its own operational needs. The event schema becomes a contract. Consumers must handle the event data they receive, and teams need monitoring for failed or delayed processing. Do not choose events merely to make an ordinary record update look more sophisticated.
Choose the trigger, then control when it actually runs
After selecting the Flow type, define entry conditions as narrowly as possible. For record-triggered flows, distinguish “the record currently meets this condition” from “the record changed into this condition.” If a notification should happen only when Status moves to Escalated, do not resend it every time an unrelated field changes while Status remains Escalated.
Consider interactions with validation rules, other flows, Apex, and the platform order of execution. Current Salesforce guidance notes that record-triggered flows participate in the transaction and can behave differently depending on before-save or after-save timing. Test with realistic combinations rather than validating each automation in isolation.
Also design for bulk operations. Data loads and integrations can change many records at once. A Flow that performs repeated queries or updates inside loops may work for one record and fail or slow dramatically at scale.
Trigger choice also affects error handling. A before-save flow that detects an invalid state can stop the transaction before downstream work begins. An after-save flow may need a fault path that records or surfaces failure after the original record exists. A scheduled or event-triggered flow runs without a user waiting on the screen, so fault handling needs operational visibility rather than relying on an interactive message.
Use the business outcome as the selection matrix
If the automation changes fields on the triggering record before commit, favor before-save. If it creates related work or performs downstream actions after commit, use after-save. If deletion is the event, use before-delete when supported by the requirement. If time owns the process, use schedule-triggered. If a person must interact, use Screen Flow. If another process should call reusable background logic, use a no-trigger autolaunched flow. If a published message owns the event, consider a platform event-triggered flow.
That matrix keeps Salesforce automation understandable. Flow Builder provides many elements, but trigger choice determines the transaction boundary before any element is placed on the canvas. Designing from that boundary produces faster, safer, and more reusable automation than choosing a Flow type after the logic has already been imagined.