Maintainable Flow comes from a few habits applied to every flow, not from one clever design. Keep each record-triggered flow narrow, give it tight entry conditions and an explicit run order. Do same-record field updates before save. Keep queries and saves out of loops. Give every data element a fault path, and pull IDs and settings out of the canvas. Name, describe, test and deploy flows like code, then watch failures weekly.
How many record-triggered flows should one object have?
There is no magic number. Salesforce's architect guidance says several well-conditioned flows perform about the same as one consolidated flow, so organize for clarity rather than count.
What hurts is overlap: two flows that write the same field, or a flow and an Apex trigger both acting on one object. The Salesforce Architects record-triggered automation guide recommends one entry point per object and warns against mixing Flow and Apex triggers there. Group flows by business purpose so each owner knows which one to open.
Set run order deliberately. When you save a before-save or after-save flow you can give it a trigger order value. Flows with lower values run first, and ties fall back to alphabetical order by API name. Salesforce suggests spacing values out, such as 10, 20, 30, so a new flow can slot in later without renumbering. Flow Trigger Explorer lists every triggered flow on an object by trigger type, so you can review and reorder them together.
When should a flow run before save and when after save?
Run before save whenever the flow only changes fields on the record being saved. Run after save when you need the record ID, or must touch other records, send messages or call actions.
Before-save flows, labelled Fast Field Updates in Flow Builder, change values in memory before the record is written. That avoids a second save and its extra trigger cycle. An after-save flow that updates its own triggering record is a common smell worth moving.
How do entry conditions stop flows from running when they should not?
Entry conditions are the cheapest performance fix in Flow. A flow that never starts uses no limits, writes no debug noise and cannot fail.
- Filter on the fields that matter, not just the object. A flow about closed opportunities should check stage, not run on every edit.
- Use the option to run only when a record is updated to meet the condition. That stops the flow firing again on unrelated edits after the condition is already true.
- Do not filter with a first-step Decision element. The flow still starts and still uses the transaction's limits.
What does bulkification mean for an admin building flows?
It means designing every record-triggered flow as if 200 records arrive at once, because data loads and integrations do exactly that. Flow batches some work for you, but loops can undo it.
- Never put Get Records, Create Records, Update Records or Delete Records inside a loop. Gather changes into a collection variable and save it once after the loop.
- Query once, then filter in memory. A single Get Records with a good filter beats several narrow queries in sequence.
- Remember that flows and Apex in one transaction share the same governor limits, including queries, DML statements and CPU time.
Flows that call external systems should also respect your API allocation, covered in our API limits guide.
How should flows handle errors so failures are not silent?
Connect a fault path to every element that touches data or calls an action. Without one, the user sees a generic error and the only trace is an email to whoever last edited the flow.
By default Salesforce emails flow failures to the admin who last modified the flow, or to the Apex exception email recipients. You choose between those in Process Automation Settings. Route it to a monitored inbox, because the last editor may have moved on.
A simple logging pattern goes a long way. Create a custom object for flow errors with fields for flow name, record ID, running user and the $Flow.FaultMessage text. Each fault path writes one record there, then shows a clear message or ends quietly. Report on it weekly.
In record-triggered flows, the Custom Error element lets you block a save with a readable message, on the page or inline on a field. It rolls back the triggering change, so use it for rules a validation rule cannot express.
Which naming and documentation habits keep flows readable?
Pick one convention, write it down and apply it to every new or edited flow. The goal is that anyone can tell what a flow does from Setup, without opening it.
- Flow names that state object, trigger and purpose, for example Opportunity - After Save - Create Onboarding Case.
- A description on every flow and every non-obvious element: what it does, who asked for it and the ticket or story reference.
- Element and variable names that read as sentences, such as Get Open Cases For Account, not Get Records 3.
- A version description each time you save a new version, saying what changed and why.
Why should IDs and settings stay out of the flow canvas?
Hard-coded record IDs, queue IDs and thresholds break when you deploy between sandboxes and production. They also force a new flow version for a simple business change.
Store settings in custom metadata types, which deploy with your metadata and can be queried in Flow with Get Records. Use custom labels for user-facing text that may need translation. Look up queues and record types by developer name. A rescue we ran for an industrial-services firm found task-creation flows built on hard-coded assignments; restructuring them around variables was part of the fix.
When should you build a subflow or an invocable action?
Build a subflow when the same steps appear in two or more flows. Build an invocable Apex action when the step needs code, such as a complex calculation or a callout pattern Flow handles poorly.
Subflows keep shared logic in one place, so a rule changes once. Invocable actions let developers give admins a tested building block that appears in Flow Builder like any standard action. Our Flow versus Apex article explains where that line usually falls.
How do scheduled paths and asynchronous paths work?
Scheduled paths run part of an after-save flow at a time relative to the trigger or a date field. The run-asynchronously path runs soon after the transaction commits, outside the user's save.
Scheduled paths suit reminders and follow-ups, such as a task three days before a renewal date. Salesforce Architects suggests the asynchronous path for work that does not need to finish inside the save, like a notification or simple callout. The flip side is that failures there never reach the user, which makes your error log and alert emails essential.
What makes a screen flow pleasant to use?
Short screens, plain labels and clear exits. A screen flow is a user interface, so it deserves the same care as a page layout.
- Ask only for what the process needs, and prefill anything the flow already knows.
- Use conditional visibility to hide fields that do not apply, instead of branching to extra screens.
- End with a confirmation screen or a redirect, so people know the work is saved.
- Test as real user profiles, since permissions change what each person sees.
How should flows be tested before they go live?
Use three layers: Flow Builder's debug for building, saved flow tests for regression and sandbox testing with realistic data for sign-off. Each catches problems the others miss.
Saved flow tests work for record-triggered and autolaunched flows, but Salesforce documents real gaps. They skip asynchronous paths and delete triggers, test data cannot use formulas, and passing tests add nothing to coverage requirements. Treat them as a safety net and check current release notes, since the feature keeps changing.
For bulk behavior, load a few hundred records in a sandbox. Single-record debug will not reveal a query inside a loop.
How should flow changes move to production?
Through the same path as any other metadata change: built in a sandbox, reviewed, tested and deployed in a planned window. Editing active flows directly in production is how orgs end up with conflicting versions.
Keep flow metadata in source control if your team has it, so changes can be compared and rolled back. Our Salesforce release management guide covers sandbox strategy, change sets and DevOps Center in more depth.
How do you monitor flows once they are live?
Review failures on a schedule rather than waiting for complaints. A weekly check of error emails, your error log and paused or failed interviews catches most problems early.
Failed interviews for flows built in Flow Builder's free-form layout can be opened in Flow Builder to show the path taken and the error. The Automation app's Monitor tab lists paused interviews, and Setup holds paused and failed flow interview views.
When is Flow the wrong tool?
When logic is deeply branched, runs over very large data sets, or needs precise error and transaction control. At that point a well-tested Apex class is easier to keep correct.
Signs include flows with dozens of nested decisions, loops over thousands of records, or repeated CPU time errors. Our Flow versus Apex guide walks through that decision.
| Practice | Why it matters | What goes wrong without it |
|---|---|---|
| Explicit trigger order | Makes the sequence of flows on an object predictable | One flow overwrites another's field, and results vary by API name |
| Before-save for same-record updates | Avoids a second save and trigger cycle | Slow saves and recursion on the triggering record |
| Tight entry conditions | Flows start only when relevant fields change | Every edit runs every flow, using limits for nothing |
| No data elements in loops | Keeps queries and saves within governor limits | Data loads and integrations fail at volume |
| Fault path on every data element | Failures are logged and users get clear messages | Generic errors and silent failures in async paths |
| Monitored error email recipient | Alerts reach someone who will act | Failures go to a former or unaware editor |
| Custom metadata instead of hard-coded IDs | Settings move cleanly between environments | Broken flows after deployment and versions for small edits |
| Naming and descriptions | Anyone can find and understand a flow | Duplicate flows built because no one knew one existed |
| Flow tests and bulk sandbox tests | Catches regressions and volume problems before release | Changes break working logic in production |
| Sandbox-first deployment | Changes are reviewed and reversible | Conflicting active versions edited live |
What does Flow cleanup look like in a real org?
It starts with symptoms users feel, then works back to design. In our industrial-services rescue, inefficient flows were firing 30 emails at once, alongside scheduling and licensing problems from a prior build.
The work included restructuring task-creation flows around variables instead of hard-coded assignments. A sensible cleanup maps every flow per object first, then fixes the worst offenders in order.
