When a Salesforce flow stops working, the cause is almost never the flow's logic — it is one of eight suspects: a deactivated version, entry conditions that no longer match, the "only when updated to meet conditions" setting, a new validation rule or required field, a permission change, a competing automation, a deactivated running user, or scheduled paths that silently canceled. The errors are usually sitting in a flow fault email or the Paused and Failed Flow Interviews list in Setup. This checklist is for admins and operations teams who depend on a flow that quietly stopped updating records — including the common case where a parent record's status is derived from child records — and it reflects how Vantage Point's managed services team triages automation failures before touching a rebuild.
A record-triggered flow has two failure modes, and only one of them makes noise. Loud failures happen when the flow fires and errors — Salesforce sends a fault email and logs a failed interview. Quiet failures happen when the flow never fires at all: the record did not meet the entry conditions, the flow version is inactive, or the record already qualified and the "only when updated" setting skipped it. Quiet failures are the dangerous ones, because nothing tells you they happened. The business notices weeks later that a status field has drifted, a handoff never occurred, or a segment built on that field is wrong.
The triage checklist below is ordered by probability and cost: start where the evidence already exists, then reproduce, then investigate what changed around the flow.
Open the flow in Setup and check the version list. A newer inactive version, an older active version after a deployment, or a flow deactivated during a previous troubleshooting session are all common. Flows do not deactivate themselves — if the active version changed, someone or something (a deployment, a managed package) changed it.
Confirm the trigger object, the trigger type (create, update, create-or-update), and every condition against a record that should have fired. Pay special attention to When to Run the Flow for Updated Records: with "Only when a record is updated to meet the condition requirements," a record that already met the conditions will not re-fire the flow on later edits. That setting is correct for preventing loops — and the single most misread line in Flow Builder.
When a flow run fails, Salesforce emails the admin who last modified the flow (or the Apex exception recipients) with the failing element and error message, plus a link to debug the error directly in Flow Builder. For failures without emails, open Setup → Paused and Failed Flow Interviews and filter to the flow. The error text names the element and usually the exact problem — a missing required input, a validation rule rejection, a governor limit.
Run the debugger with a record that should trigger the flow and watch the path it takes. If the debugger shows the flow exiting at the start conditions, the logic is fine and the entry criteria are the problem. If it fails mid-path, the failing element tells you where to dig.
Flows live inside Salesforce's order of execution, sharing the transaction with validation rules, other flows, Apex triggers, and duplicate rules. A new validation rule or newly required field will reject the flow's update even though the flow itself is unchanged — the error email says "validation rule," and teams misread that as the flow failing. Check recent setup audit trail entries for the object: new validation rules, field-level security changes, new required fields, record type changes, and any automation deployed in the window when failures began.
Record-triggered flows run in system context for field-level security on many operations, but user permissions still matter for actions the flow takes, and scheduled flows run as a specific user — if that user is deactivated, the scheduled work stops. Platform events, approver changes, and integration users all leave similar fingerprints. Match the failure start date to user deactivations and integration credential changes.
Flows that work on single records can fail in bulk: SOQL or DML limits inside loops, CPU timeouts, or UNABLE_TO_LOCK_ROW contention when a data load or integration touches the same records. If failures cluster around import windows or integration syncs, the flow is a victim of contention, not a cause.
Scheduled paths follow their own rules: they are canceled when the record stops meeting the conditions, retried a limited number of times on failure, and visible in Setup under Time-Based Automations. A flow that "stopped working" is sometimes a flow whose scheduled path was canceled by an edit that took the record out of criteria — working as designed, surprising anyway.
One of the most common business automations is a parent status derived from child records — an account flagged as a current client when any related commitment is active, and reset to former client when all of them terminate. These flows break in a distinctive way: they work perfectly in testing and then drift silently in production, because the logic usually watches the child object and misses an edge case — a deleted child record, a bulk update that errored halfway, a status value nobody mapped, or an entry condition that skips exactly the edit that should trigger recalculation.
If you own one of these, three design rules prevent most silent drift:
Rebuild only when the flow's design is the problem: logic that increments instead of recalculates, before-save flows asked to do after-save work, or automation stacked so deep on one object that nobody can predict the transaction. Otherwise, the checklist above finds the cause faster than a rewrite — and a rewrite that inherits the same unexamined assumptions will fail the same way. If your team is carrying several fragile flows, it may be time for a broader automation architecture review rather than another round of patching.
Vantage Point's senior consultants troubleshoot and redesign Salesforce automation as part of managed services and ongoing support — flow error monitoring, automation audits, and order-of-execution cleanup included. For teams planning net-new automation, our Salesforce implementation and advisory practice designs flows that fail loudly, recalculate instead of drift, and come with the monitoring to prove they are still working. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver. For a broader view of where flow fits your automation roadmap, see our CRM automation guide.
If a flow your business depends on has stopped working — or you suspect one has — Vantage Point can run this triage with you, fix the root cause, and put monitoring in place so the next failure is loud. Contact Vantage Point to schedule a working session, or explore managed services for ongoing automation care.
The most common reason is the entry conditions, especially the "Only when a record is updated to meet the condition requirements" setting — a record that already met the conditions will not re-fire the flow on later edits. After that, check that the expected version is active and that nothing about the record's data changed so it no longer matches the criteria.
Go to Setup and open Paused and Failed Flow Interviews, then filter to your flow. Failed runs show the error and the element that caused it. For scheduled work, also check Time-Based Workflow or the time-based automations monitoring page in Setup.
Flow fault emails go to the admin who last modified the flow, or to the org's Apex exception email recipients, depending on configuration. If your team never sees fault emails, check both — and consider routing them to a shared admin inbox so failures are visible to more than one person.
Yes. A validation rule fires inside the same transaction as the flow's update, and if the flow writes data the rule rejects, the whole transaction fails — the flow gets blamed for the validation rule's rejection. When failures start suddenly, check the setup audit trail for validation rules, required fields, and field-level security changes made around the same time.
No — flows do not deactivate themselves. If the active version changed or the flow is inactive, check the setup audit trail for a deployment, a managed package upgrade, or an admin change. This is why an automation change log matters: the answer to "what changed" should never require detective work.
Use a record-triggered flow on the child object that recalculates the parent's status from the full set of related child records on create, update, and delete — rather than toggling the parent based on the single record that changed. Add a nightly scheduled flow that recalculates everything as a safety net, so any missed trigger self-corrects within a day instead of drifting silently.
Only after the checklist proves the design is the problem. Most failing flows have a single identifiable cause — an entry condition, a validation conflict, a running-user issue — and rebuilding without naming that cause usually reproduces the same failure with new logic. Rebuild when the design itself is wrong: increment-based roll-ups, before-save flows doing after-save work, or unreadable automation stacks.
Vantage Point is a boutique CRM consulting firm helping businesses transform with Salesforce, HubSpot, and AI. Learn more at vantagepoint.io.