# Salesforce automation audit: which old rules still write to your opportunities

https://salesbond.app/blog/salesforce-automation-audit-workflow-rules-process-builder-flows/
Published: 2026-10-24 · Updated: 2026-10-24

A Salesforce automation audit is a list of every rule, process and flow that writes to your opportunities, with the field it writes, what triggers it, who owns it, and whether it overwrites what a rep typed. Start with the Workflow Rules and Process Builder processes Salesforce retired from support at the end of 2025. They are the ones nobody has looked at in years.

This is not a migration guide. Admins have plenty of those. This is the sales manager’s half of the job: knowing what is quietly editing your deals before anyone touches the automation.

## Automations edit deals when nobody is looking

A rep moves an opportunity to Negotiation, and the close date jumps to the end of the quarter. She did not do that. A workflow rule built in 2019 did, because someone back then decided every late-stage deal should “land in the quarter”. The rep fixes the date. Next week it jumps again.

Multiply that by every rule that has survived three admins, and your pipeline is partly what your team believes and partly what the automation believes. Your forecast review is arguing with a ghost.

We think the manager has to own this list, not the admin. The admin knows how the rule is built. Only you know whether a close date pushed to quarter end is a sensible default or a lie your report has been telling you since 2019.

So the goal is modest: a document that says, for each automation touching Opportunity, what it changes and whether you still want that. Nothing gets switched on or off during the audit. That part belongs to the admin, with your list in hand.

## What Workflow Rules and Process Builder retirement actually means

Salesforce no longer supports Workflow Rules and Process Builder as of December 31, 2025 ( [Salesforce Help: Workflow Rules & Process Builder End of Support](https://help.salesforce.com/s/articleView?id=001096524&language=en_US&type=1)). The same page is clear about what that does and does not mean: your active rules and processes continue to run as they did before, and the only change is that Salesforce no longer provides customer support or bug fixes for them.

Both halves matter for a sales manager.

The first half means nothing was switched off on January 1. The rule that pushes your close dates is still pushing them. If you assumed the old automation died with the deadline, your audit starts from a false premise.

The second half means that when one of those rules does something odd, Salesforce support won’t help you with it and won’t fix the bug. Salesforce recommends moving the automation to Flow Builder as soon as possible and points to its Migrate to Flow tool ( [same page](https://help.salesforce.com/s/articleView?id=001096524&language=en_US&type=1)).

That is why the old rules go first. Not because flows are harmless but because the old ones are unsupported and undocumented at the same time.

## The five questions for every rule that touches an opportunity

Ask these about each Workflow Rule, each Process Builder process and each record-triggered flow on the Opportunity object. Write the answers down.

![Audit card for one automation: five rows, from the field it writes to whether a Flow replacement exists](https://salesbond.app/wp-content/uploads/2026/10/salesforce-automation-audit-workflow-rules-process-builder-f-2.png)

1. Which Opportunity field does it write? Stage, Amount, Close Date, Owner, Probability, Next Step, a custom forecast category. If the answer is “it only sends an email” or “it creates a task”, note it and move on. Task-creating flows are a separate audit, and we wrote one for [flows that create tasks on stale opportunities](https://salesbond.app/blog/salesforce-flow-stale-opportunity-task/). Field updates are what you are hunting.
2. What makes it fire? A stage change, an amount above a threshold, a date passing, any edit at all. “Any edit” is the dangerous one: a rule that fires on every save re-applies it’s value every time the rep corrects it.
3. Does it overwrite what a rep typed? The admin will not ask this, because to the admin a field update is a field update. To you, a rule that fills an empty Next Step is a helper, and a rule that replaces a typed close date is a data-quality problem with a schedule. When the rule’s definition leaves it unclear, [field history on that Opportunity field](https://salesbond.app/blog/salesforce-field-history-tracking-opportunity-audit/) is where the pattern shows up.
4. Who owns it? Someone who can say today why it exists, not whoever’s name sits on the definition. If that person left, the neutral version of this audit covers [what to do when the builder is gone](https://salesbond.app/blog/crm-automation-sales-manager-audit/#who-owns-the-rule-when-the-person-who-built-it-leaves).
5. Is there a Flow replacement? Three honest answers: yes and the old one should be retired, no and someone needs to build one, or “we don’t need this anymore”. The third is more common than admins expect, and only the sales manager can give it.

Five questions, every rule. An org that has been on Salesforce for years can fill a long table from Opportunity alone. It is still a working session with the admin, not a project.

## Where to look: the list the admin gives you

You do not need Setup access to run this audit and we would argue you should not be editing anything in there anyway. Ask your admin for the export. It helps to know what you are asking for.

Salesforce’s end-of-support page says where the old automation lives. For Workflow Rules: Setup, then Process Automation, then Workflow Rules, and sort the Active column for checkmarks. For Process Builder: Setup, then Process Automation, then Process Builder, and sort the Status column for Active ( [Salesforce Help](https://help.salesforce.com/s/articleView?id=001096524&language=en_US&type=1)). That is the admin’s starting list. Record-triggered flows on Opportunity are a separate list, so ask for them in the same request.

What you want back is one table, not screenshots of criteria: automation name, type (Workflow Rule, Process, Flow), active or not, the fields it updates, the trigger condition in plain words, last modified date, last modified by. If the last column is full of people who have left, you already know how the audit is going to go.

Then go through the five questions together, row by row. The admin answers one and two from the definition. You answer three and five from how your team actually sells. Four is a shared embarrassment.

One restriction we hold to: the manager’s output is the list and the decisions. Deactivating a rule, even an obviously dead one, is the admin’s call, made after they check what else depends on it. A rule that looks useless from the the opportunity side may be feeding a report you have never seen.

## Migrate to Flow, one to one, can leave you with a pile of flows

Here is where the sales manager’s list earns its keep.

Salesforce points to its Migrate to Flow tool as the way off the old automation ( [Salesforce Help](https://help.salesforce.com/s/articleView?id=001096524&language=en_US&type=1)). Sikich, an integrator that published a transition guide for admins, describes the practical side. By their account, the tool converts each rule or process into its own flow, so five workflow rules on one object become five separate flows. It does not support every configuration; Sikich names rules involving record types, fields on related records and multiple currencies. And the converted flows may need further adjustments before they do what you need. Sikich also recommends consolidating to no more than three flows per object ( [Sikich: transitioning from Workflow Rules and Process Builder](https://www.sikich.com/insight/your-guide-to-transitioning-from-salesforce-workflow-rules-and-process-builder-before-end-of-support/)).

Sikich presents “three per object” as Salesforce best practice. Salesforce’s end-of-support page doesn’t mention it, so we treat it as an integrator’s rule of thumb, not a platform limit. The arithmetic behind the advice holds either way: thirty workflow rules on Opportunity converted one to one become thirty flows on Opportunity, with the same undocumented overwrites, now in a newer tool. The migration keeps the problem and gives it a fresh coat of paint.

The five questions prevent exactly that. If your list already says which rules overwrite rep input and which ones nobody needs, the admin migrates the handful that matter instead of all thirty, and consolidates them into a few flows with a known owner. The audit is cheap. Migrating things you should have deleted is not.

## What to keep in your own file after the audit

The admin keeps teh Setup side. You keep a short document, outside Salesforce, that survives the next admin change. Ours has four parts.

The table itself, with the five answers per row and a decision column: keep, replace, retire, ask. Decisions dated and initialled, so nobody re-litigates “do we still need the renewal amount rule” in a year.

Write down which Opportunity fields automation may write and which it may never overwrite. For us, Close Date and Amount are rep-owned: automation may fill them when empty but never replace a typed value. Stage is rep-owned, full stop. Your team’s split will be its own. Whatever it is, this is the sentence that ends the quarter-end close date argument for good.

The names of the people who can answer for each surviving automation. Two names per row if you can manage it.

A date for the next pass. Flows accumulate the way rules did; the tooling changed, the habit did not. Twice a year is enough for most teams.

If you want the platform-neutral version of this method, we covered it in [the CRM automation audit for sales managers](https://salesbond.app/blog/crm-automation-sales-manager-audit/); this article is the Salesforce-specific half. For what else to check on the object once the automation is accounted for, there is [the opportunity audit for sales managers](https://salesbond.app/blog/salesforce-opportunity-audit-sales-manager/) and [validation rules for required opportunity fields](https://salesbond.app/blog/salesforce-validation-rules-opportunity-required-fields/).

A disclosure, since deal hygiene is what we work on: we build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive. Its Deal Health product checks open deals against more than 20 rules and flags violations your team can resolve, snooze or ignore, which is an ongoing watch on the pipeline once the audit is done. It does not replace the audit. [Check your CRM with SalesBond](https://salesbond.app/) if you want that watch; the list above is still yours to make.

Most of the old rules you find will be harmless, and a few will be useful. Two or three will have been editing your forecast for years without anyone deciding they should. So send your admin the request for that one table this week, and book an hour to go through it together before anything gets migrated into something newer that gives those two or three another decade.