When Salesforce automation has accumulated over several years, the visible problem is rarely the whole problem. Before changing a Flow, Apex trigger, approval process, assignment rule, or legacy automation rule, an administrator needs to understand what is active, what overlaps, what writes downstream, and what the business still depends on.
This audit is for inherited orgs where nobody wants to break a critical handoff because a rule looked old in Setup. The goal is not to delete everything legacy. The goal is to separate what should be retained, repaired, consolidated, migrated, or retired with evidence.
Why automation audits matter
Salesforce automation can run through several layers during a record save. Before-save record-triggered flows, Apex triggers, validation rules, duplicate rules, workflow actions, assignment rules, escalation rules, after-save flows, and post-commit logic can all matter depending on the object and transaction. That is why an audit has to look at order of execution, not just a list of active Flows.
A good audit reduces change risk. It helps you see where automation overlaps, where failures are hidden, where a process still supports a business exception, and where a legacy tool should be migrated only after the current behavior is understood.
Start with the business symptom
Do not begin by opening Setup and deactivating things. Begin with the problem the business sees.
- Records are getting assigned to the wrong owner.
- Opportunity amounts, stages, dates, or rollups are changing unexpectedly.
- Email alerts are firing twice or not at all.
- A Flow fails after a user edits a record.
- A report no longer matches what sales or operations expects.
The symptom tells you which object, field, timing, user action, and downstream process to trace first.
Inventory every automation type
Inherited orgs often contain more automation than the current admin team realizes. Include each layer before deciding what is redundant.
- Flows: record-triggered, screen, scheduled-triggered, autolaunched, platform event-triggered, and subflows.
- Apex: triggers, classes, scheduled Apex, queueable Apex, future methods, batch jobs, and managed-package code that touches the same object.
- Approval processes: entry criteria, approval steps, field updates, email alerts, and final actions.
- Legacy declarative automation: Workflow Rules and Process Builder processes that still exist in the org.
- Object rules: validation rules, duplicate rules, assignment rules, escalation rules, auto-response rules, and sharing criteria.
- Integrations and packages: middleware, AppExchange packages, API users, and external jobs that update the same records.
Use Setup, Flow Trigger Explorer, debug logs, metadata exports, package documentation, and admin interviews together. Metadata review is necessary, but it does not prove runtime behavior by itself.
Identify what is active
For each automation, record whether it is active, which version is active, the object it runs on, and whether it runs before save, after save, on a schedule, from a button/action, from a platform event, or from another automation.
Inactive versions still matter because they explain history and sometimes contain logic someone expects to restore. Active versions matter because they are what the org is actually running today.
Trace entry conditions
Entry criteria are where many overlaps hide. Two automations may look different until you realize both run when an Opportunity moves to Closed Won, both update related records, and both assume they are the only writer.
- Capture object, record type, field-change conditions, formulas, and user/profile conditions.
- Check whether a Flow is optimized for before-save field updates or after-save related-record work.
- Note whether the automation runs for create, update, delete, or both create and update.
- Document anything that relies on a specific user, integration user, queue, public group, role, or permission.
Map downstream updates and side effects
Automation is rarely isolated. One field update may retrigger rules, update a parent record, send an email, create a task, change ownership, or affect a dashboard. Map what each automation writes and what those writes can trigger next.
For consulting work, this is where the risk usually becomes visible. A small field cleanup can break pipeline reporting if that field feeds a Flow, validation rule, formula, integration, or executive dashboard.
Related project example: pipeline target rollups.
Review fault handling and failed interviews
Do not treat a Flow as healthy just because it is active. Review failed and paused Flow interviews, fault connectors, error emails, debug logs, and user-reported exceptions.
- Does the Flow have fault paths on elements that can fail?
- Does the error message help an admin diagnose the issue?
- Does the failure leave a partial business process behind?
- Are retries handled manually, automatically, or not at all?
For Apex, pair this with test coverage, logs, and code review. A passing test percentage alone does not prove the current business path is safe.
Look for overlapping automation
Overlap is not always bad. It becomes risky when multiple automations update the same fields, enforce similar rules, or assume different definitions of the same process.
- Multiple record-triggered flows on the same object and event.
- Flow plus Apex trigger writing to the same field.
- Workflow field update plus after-save Flow side effects.
- Approval action plus validation rule conflict.
- Assignment rule plus owner-change Flow or email alert.
- Duplicate rule blocking a record before downstream automation can run.
Use the current Salesforce order of execution as the frame. The same record save can pass through validation, duplicate rules, triggers, workflow actions, flows, assignment rules, escalation rules, and post-commit work.
Separate legacy from obsolete
Workflow Rules and Process Builder require careful wording. They are legacy automation options that Salesforce has recommended moving to Flow where practical. In many orgs, existing rules or processes can still execute. The risk is assuming legacy means safe to delete.
Use these categories instead:
- Retain: still correct, business-owned, tested, and documented.
- Repair: useful logic with errors, unclear ownership, or missing fault handling.
- Migrate: legacy logic that should move to Flow after testing and business review.
- Consolidate: overlapping automations that should become one clearer path.
- Retire: no longer used, no hidden dependency found, and approved for removal.
Do not state that an old rule has disappeared unless you have checked that specific org. Do not remove a legacy automation just because a newer tool exists.
Identify business-critical exceptions
The messiest automations often exist because a customer, division, product line, exception approval, or integration needed special handling. The logic may look strange until the business owner explains why it exists.
Before changing it, identify the owner, the exception, the records affected, and how the team will know if the change works.
Test before changing anything
Use a sandbox or a controlled change scope when possible. Build test records that represent normal cases and edge cases. Include different profiles, record types, ownership paths, currencies, products, regions, or business units if those factors change automation behavior.
For Apex-backed behavior, review tests and run the relevant test classes. For Flow-backed behavior, debug the Flow, test the record save path, and verify side effects after commit.
Document the current state
The audit should leave behind a usable handoff. A spreadsheet is fine if it is maintained. A private admin note is fine if the team can find it. The format matters less than the discipline.
| Field | What to capture |
|---|---|
| Automation name | Exact Flow, rule, process, trigger, approval, or package name. |
| Automation type | Record-triggered Flow, Screen Flow, Apex trigger, approval process, Workflow Rule, Process Builder, assignment rule, escalation rule, duplicate rule, or integration. |
| Active version | Active version or active/inactive status. Include inactive versions only as historical context. |
| Triggering object | Object, record type, event, schedule, platform event, or screen action. |
| Entry criteria | Field-change logic, formulas, user conditions, and assumptions. |
| Run timing | Before save, after save, scheduled, post-commit, screen-driven, or called by another automation. |
| Downstream updates | Fields, related records, emails, tasks, owner changes, rollups, integrations, and reports affected. |
| Error handling | Fault paths, error emails, failed interviews, Apex exceptions, and retry plan. |
| Business owner | Person or team that confirms the process is still needed. |
| Last known use | Evidence from records, logs, interviews, or scheduled activity. Do not rely on metadata alone. |
| Test coverage | Flow debug notes, sandbox test records, Apex tests, and user acceptance checks. |
| Recommended action | Retain, repair, migrate, consolidate, retire, or investigate further. |
Decide what to keep, repair, migrate, consolidate, or retire
Once the evidence is gathered, prioritize by risk. Start with automations that affect revenue, customer communication, ownership, compliance, integrations, and executive reporting. Leave cosmetic cleanup for later.
If your org has years of Flow, Apex, Workflow Rules, Process Builder, and undocumented exceptions layered together, this is the kind of controlled cleanup covered in my Salesforce services.
When to bring in outside help
Bring in help when the automation touches revenue reporting, critical handoffs, integrations, managed packages, Apex, or business processes nobody currently owns. The work is not just finding old automation. It is proving what still matters before changing it.
A safe audit should end with a smaller, clearer system and a record of why each change was made.