Flow Builder is Salesforce's visual, drag-and-drop automation tool used to build business logic without writing code — from simple field updates to complex multi-step processes.

Screen Flow (interactive, user fills out screens), Record-Triggered Flow (fires automatically on record create/update/delete), Scheduled Flow (runs at a set time, no trigger needed), and Autolaunched Flow (runs silently via Apex, button, or another Flow).

A Before-Save Flow updates fields on the SAME record before it's committed to the database — fast, with no extra DML needed. An After-Save Flow runs after the record is saved and can update OTHER records, send emails, or call Apex.

A Screen Flow displays interactive screens for a user to fill out and click through. An Autolaunched Flow runs entirely in the background with no user interface at all.

When multiple Record-Triggered Flows exist on the same object, Salesforce groups their Before-Save (Fast Field Updates) elements together first, then runs all After-Save (Actions and Related Records) elements — regardless of which Flow was created first, unless explicit ordering is set.

A Decision element branches the Flow's execution path based on conditions — functioning like an if/else statement, routing down different paths depending on which condition is met.

An Assignment element sets or changes the value of a Flow variable — assigning a value, adding to a collection, or performing simple math like incrementing a counter.

The Loop element iterates through a collection of records or values one at a time, letting the Flow perform an action on each individual item in that collection.

Get Records queries Salesforce data within a Flow — similar to a SOQL query — retrieving one or more records matching specified filter criteria for use later in the Flow.

A Fault Path is an alternate path a Flow takes when an element (like a DML operation) fails — letting the Flow handle errors gracefully instead of showing the user a raw, confusing system error.

Yes — through an Invocable Method, an Apex method annotated with @InvocableMethod that Flow recognizes and can call as an action.

Yes, using a Subflow element — one Flow can call another Flow as a reusable component within it, passing variables in and out.

A Formula Resource is a reusable calculated value within a Flow — built using formula syntax similar to Formula fields — that can reference Flow variables and be used across multiple elements.

A Record Variable holds ONE single record's worth of field values. A Collection Variable holds MULTIPLE records (or values) — essentially a list.

This happens when the Flow tries to access a field on a Record Variable that's actually null — commonly because a Get Records element found NO matching record but the Flow proceeds as if it did.

Use precise entry conditions that only fire the Flow when a SPECIFIC field actually changed — not on every save — and avoid unconditional updates back to the same triggering object without a change-detection check.

Sort Order controls which order records are returned in when Get Records retrieves multiple results — for example, sorting by CreatedDate descending to get the most recent record first.

Automatically Store All Fields pulls every field on the object into the Flow's memory, which is convenient but can hit heap size limits and slow performance at scale. Manually selecting fields (Advanced mode) pulls only what's needed.

A Constant is a named, fixed value that never changes during Flow execution — used to avoid hardcoding the same value (like a specific picklist string) in multiple places throughout a Flow.

A Text Template is a rich-text resource designed for building formatted, multi-line content (like an email body) that can merge in Flow variables. A plain Text Variable just holds a single string value.

Process Builder was a visual automation tool (predecessor to Flow) using a linear 'if this, then that' structure. Salesforce has officially retired it — Flow Builder is now the standard tool for all new automation.

A Scheduled-Triggered Flow (Scheduled Flow) runs automatically at a specified date/time and frequency without needing a record to be created or edited — commonly used for batch-style cleanup or reminder processes.

Without a Fault Path, the Flow simply stops execution at that point and the user sees a generic, unhelpful Salesforce error message — with no logging, no graceful handling, and no way for an admin to know it happened unless the user reports it.

Some Flow elements (like Send Email or Create Records) offer a Run Asynchronously connector option specifically for the Fault Path, which processes error handling in the background without blocking the main Flow's execution.

A Record-Triggered Flow fires when a standard Salesforce record (Account, Case, custom object, etc.) is created, updated, or deleted. A Platform Event-Triggered Flow fires when a Platform Event message is published — useful for real-time, decoupled system integration.

Lightning App Builder is Salesforce's drag-and-drop tool for building custom Record Pages, App Pages, and Home Pages. Screen Flows can be embedded directly into these pages as a Flow component.

'Update Triggering Record' (available in Before-Save Record-Triggered Flows) directly modifies the record that triggered the Flow with zero extra DML. The Get Records + Loop + Update pattern is needed when updating a DIFFERENT set of records than the one that triggered the Flow.

Flows share the same underlying platform governor limits as Apex within a transaction — 100 SOQL queries, 150 DML statements, and so on — meaning a poorly designed Flow with Get Records inside a Loop can hit the exact same limits as unbulkified Apex code.

Input variables pass data INTO a Subflow from its parent Flow; output variables pass results BACK OUT from the Subflow to the parent — this is how data flows between a reusable Subflow and whatever calls it.

This setting controls whose permissions the Flow uses when reading/writing data — 'System Context Without Sharing' bypasses the running user's field-level security and sharing rules entirely, while 'User Context' respects them.

This is almost always a Field-Level Security or Object permission issue — if the Flow runs in 'User Context' and the Sales Rep's Profile doesn't have edit access to a field the Flow tries to update, the Flow fails for them specifically, even though the admin's Profile has full access to everything.

A Screen component is a single input/display element on a Screen Flow's screen — like a text input, picklist, or data table. Yes, custom LWCs can be exposed as Screen Flow components, letting developers build fully custom UI pieces that admins can drag into any Screen Flow.

Single mode creates ONE record using a Record Variable's values. Multiple mode creates MANY records at once using a Collection Variable — firing a single bulk DML statement instead of one per record.

A Flow Interview is a single running instance of a Flow's execution — every time a Flow runs (triggered, launched by a user, etc.), Salesforce creates a Flow Interview that Debug mode can trace step-by-step.

The Pause element temporarily halts a Flow's execution, waiting for a specific condition or a set amount of time to elapse before resuming — useful for approval-style waiting periods within a Flow.

A Choice resource defines a single selectable option (with a label and stored value) for use in Screen components like Radio Buttons, Checkbox Groups, Picklists, or Dropdowns on a Screen Flow.

A Variable can change its value during the Flow's execution (through Assignment elements, user input, or query results). A Constant is fixed and never changes once defined.

Collect the value using a Screen component into a Flow Variable, then pass that variable as an input to an Invocable Apex Action — the Apex method receives it as a parameter in a bulk-safe List format.

This happens when the Flow tries to update a record that's currently locked by ANOTHER concurrent transaction updating the same record (or a related record with a shared parent) at the same moment — a classic concurrency issue, not a logic bug in the Flow itself.

This option returns EVERY record of the selected object type with zero filtering — extremely dangerous in production since it can return millions of records, instantly hitting the 50,000-row SOQL limit and crashing the Flow.

Fast Field Update covers Before-Save Flow logic (fast, same-record updates only). Actions and Related Records covers After-Save Flow logic (emails, related record DML, Apex calls). Trigger Order settings apply separately within each of these two phases.

This option on certain Flow elements allows the Flow to roll back JUST the changes made by that Flow, without necessarily rolling back the entire surrounding transaction (like other automation that ran successfully alongside it).

Salesforce provides an official 'Migrate to Flow' tool (Setup → Flows → Migrate to Flow) that analyzes an existing Workflow Rule or Process Builder and auto-generates an equivalent Flow — though the result should always be reviewed and tested before activating.

The Default Outcome is the path a Decision element takes when NONE of the defined conditions match — always including one prevents the Flow from silently doing nothing (or erroring) when an unexpected value slips through.

A Quick Action-launched Screen Flow opens in a modal/popup overlay triggered by a button click. An App Builder-embedded Screen Flow renders directly inline as part of the Record Page layout, always visible without needing a button click.

The Element Toolbox is the left-side panel in Flow Builder listing all available Flow elements (Get Records, Decision, Loop, Assignment, Screen components, Action calls, etc.) that can be dragged onto the canvas to build the Flow's logic.

A Record Choice Set dynamically pulls its options from actual Salesforce records matching a filter — automatically staying current as data changes. A manually built Choice list is static and must be updated by hand whenever the underlying options change.

This is expected Flow behavior — by default, Screen Flow inputs retain their previously entered values when a user navigates back and forward, unless the Flow is explicitly designed to reset them.

Flow Trigger Explorer (Setup → Flow Trigger Explorer) gives admins a consolidated view of ALL Record-Triggered Flows active on a given object, showing their trigger order and phase (Before-Save vs After-Save) in one place.

Always test with the Debug tool BEFORE activating a Flow, tracing every Decision path and variable value step by step — rather than activating first and discovering problems only when real users hit unexpected behavior.