10 signs your Salesforce automation needs a checkup
A practical checklist to find colliding Flows, silent failures and legacy automation before they cost you. Includes the setup pages and queries to run.
Most Salesforce orgs collect automation the way a kitchen drawer collects cables. Each Flow, trigger and rule made sense the day it was built. Years later, nobody is sure what fires when a record is saved.
This is the checklist we start from in our automation healthchecks. You can run most of it yourself in an afternoon.
1. More than one automation fires on the same event
Pick your busiest object, usually Account, Opportunity or Case. List everything that runs when a record is created or updated: record-triggered Flows, Apex triggers, Workflow Rules and Process Builders.
In Setup > Flow Trigger Explorer you can see the record-triggered Flows for one object in order. If you see several Flows on the same trigger with no explicit order, the order they run in is not guaranteed to be the one you expect.
2. Workflow Rules and Process Builders are still active
Salesforce retired both tools in favor of Flow. They still run, but they no longer receive improvements, and they mix badly with Flows on the same object. Setup > Migrate to Flow converts many of them for you. Test each one in a sandbox before switching it off.
3. Flow error emails go to someone who left
When a Flow fails, Salesforce emails the person who last modified it, or the address set in Setup > Process Automation Settings. Check that address. If it belongs to a former employee, your failures have been silent.
4. The same error appears every week
Search your inbox, or the error recipient's, for "Error Occurred During Flow". Group the messages by Flow name. One Flow causing most of the errors is the cheapest fix in the org.
5. Triggers have logic inside them
A trigger with hundreds of lines and no handler class is hard to test and impossible to order. One trigger per object, calling a handler class, is the pattern to aim for.
6. Queries or updates inside loops
In both Apex and Flow, a Get Records or Update Records element inside a loop works with 5 records and fails with 200. If bulk data loads fail while single edits work, this is usually why.
7. Hard-coded IDs
Record type IDs, user IDs and queue IDs typed directly into Flows or Apex break the moment you deploy to another org or refresh a sandbox. Look them up by developer name instead.
8. Flows with no description and a version count in the dozens
Setup > Flows shows each Flow's latest version. Twenty versions and an empty description means people have been editing it without anyone owning it.
9. Test coverage that barely passes
Run all tests from Setup > Apex Test Execution and look at org-wide coverage. Coverage near 75% means every deployment is one failed test away from being blocked.
10. Nobody can explain what happens when a record is saved
Ask the admin and a sales or service manager to describe what happens when an opportunity is closed won. If the answers differ, or if nobody can say, the automation has outgrown its documentation.
What to do with your findings
Write each finding down with the object, the automation name and what goes wrong. Then rank them by how many users each one affects. That list is your backlog.
Prefer a second pair of eyes? Our free automation healthcheck covers all of this and more in 10 hours of read-only review, and you keep the written report.