7.2 Flow Builder: Screen, Record-Triggered, Scheduled, and Autolaunched Flows

Flow types and when they fit

A screen flow is an interactive experience. It can ask questions, show choices, validate user input, create records, update records, and branch based on values. Use it when the user needs guidance, when the process spans several objects, or when the standard page layout cannot express the decision path clearly. A screen flow can be launched from a Lightning page, quick action, utility bar, Experience Cloud site, or other supported entry point.

A record-triggered flow runs because a record changes. It can run when a record is created, updated, deleted, or meets criteria. Before-save flows are efficient for changing fields on the same record. After-save flows are needed when the flow must create related records, update other records, send notifications, call actions, use the saved record ID, or run paths after the record is committed. Entry criteria should be narrow enough to avoid needless interviews.

A scheduled-triggered flow runs at a configured date and time and can select records that meet criteria. It is useful for recurring maintenance such as creating renewal tasks, marking stale onboarding items, or checking records that need follow-up. It should not be used as a substitute for real-time automation when users expect immediate results. Scheduled flows also need volume judgment because they can process many records at once.

An autolaunched flow has no screen and can be called by other automation, Apex, buttons, actions, external integrations, or another flow as a subflow. It is useful for reusable logic, such as calculating a service entitlement result or creating a standard set of onboarding records. Reuse is valuable only when the input and output contract is clear. A vague subflow can spread risk across many callers.

Flow design aid

Flow Builder is reached from Setup > Process Automation > Flows. A practical admin also knows where the flow is used. A flow may be on a Lightning record page, invoked by a button, referenced by a quick action, started by another flow, called from Apex, or exposed through automation settings. Before editing, inspect activation status, latest version, dependencies, and where-used information where available.

Decision elements should read like business policy. Instead of a decision named Check 1, use names such as Discount Requires Approval or Case Needs Premium Escalation. Outcomes should be mutually understandable, and the default outcome should be deliberate. Assignment elements should have clear variable names. Get Records elements should retrieve only the fields and rows needed. Collection variables should be used when multiple records must be updated together.

Fault handling is not optional in serious flows. Record creates and updates can fail because of validation rules, missing permissions, duplicate rules, locked records, lookup filters, required fields, or data type problems. A screen flow should show a helpful error or recovery path. A background flow should use fault connectors where useful, log details to an admin-owned object or platform event when the org has that pattern, and avoid hiding failures from operations.

Build, test, and activate with discipline

Flow testing should start in a Trailhead Playground, Developer Edition org, or sandbox before production. Create sample records for each branch, including records that should not enter the flow. Test as users with different permissions when the flow runs in user context or when field-level security matters. If the flow updates records the user cannot normally edit, understand whether system context is appropriate and document the reason. Running everything in elevated context can create security surprises.

A focused flow build workflow:

1. Write the business trigger, entry criteria, expected outputs, and exception path.
2. Choose the flow type and context that fit the requirement.
3. Build the smallest viable flow with clear element names.
4. Add fault paths for record operations and user-facing error handling for screen flows.
5. Debug with records that cover every decision outcome.
6. Test bulk updates, import behavior, validation conflicts, and user permissions.
7. Activate a new version during a controlled release window and monitor failures.

Screen flows need user experience care. Do not show every possible field just because the data exists. Use choice sets for controlled options, required inputs where the step cannot continue without data, and clear labels that match business terms. Keep screens short, group related fields, and avoid asking users for data Salesforce can derive. If the flow creates records, show a confirmation or navigate the user to the result.

Record-triggered flows need recursion care. If a flow updates the same object that triggered it, it may cause another save and another interview unless criteria or change checks stop it. Use entry conditions such as only when a record is updated to meet the condition, compare prior values where available, and avoid updating the triggering record in after-save flows when before-save logic would work. Document intentional re-entry.

Scheduled flows need operational ownership. Someone must know when they run, how many records they process, what happens on failure, and what reports prove they worked. If a scheduled flow sends notifications, create guardrails so users are not spammed after a data load. If a scheduled flow changes statuses, test records near boundary dates and time zones. Automation is successful only when the operations team can understand and support it after activation.