Building record-triggered and screen flows

Record-triggered flows come in two speeds. A before-save flow quickly changes fields on the record that triggered it. An after-save flow can touch other records, send emails, and call actions. Good flows have tight entry conditions, keep data changes out of loops, and handle faults.

Before-save vs after-save

• Fast Field Updates (before-save): Updates fields on the triggering record before it is saved. No extra save is needed, so it is much faster. It can't create or update other records or send emails.
• Actions and Related Records (after-save): Runs after the record is saved. It can create, update, or delete other records, send emails, post to Chatter, and call subflows and actions. The record's ID is available.
• Scheduled paths: Run part of an after-save flow later, relative to a date on the record or to when it was saved, such as three days before Close Date.
• Run asynchronously: An after-save path that runs in the background, which suits slow work such as calling an external system.

Core Flow Builder elements

• Get Records: Finds records and stores them in a variable or collection.
• Create, Update, and Delete Records: Change data. Each runs as one database operation, even for a collection.
• Decision: Branches the flow based on conditions, like an if/else.
• Assignment: Sets or changes variable values, including adding items to a collection.
• Loop: Steps through each item in a collection.
• Screen: Shows fields and components to a user (screen flows only).
• Action and Subflow: Call an action such as sending an email, or run another flow.

Good flow design

• Entry conditions: Make the flow run only when it should, such as only when Status changes to Closed, so it doesn't fire on every edit.
• No data changes inside loops: Collect changes in a collection with Assignment, then use one Update Records after the loop. Data changes inside a loop can hit governor limits.
• Fault paths: Connect a fault path from data and action elements to handle errors, for example by showing a friendly message or logging the error.
• Running context: Screen flows run in the user's context by default. Record-triggered flows run in system context. Choose carefully when a flow touches records the user can't see.
• Variables and resources: Variables, constants, formulas, and text templates hold values. Mark a variable available for input or output to pass values in and out of the flow.