Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

In one sentence: count the active automations on your busiest object, and the number tells you which problem you have — under 15 is a documentation problem, 15 to 30 is a consolidation problem, and over 30 is an architecture problem that consolidation will not fix. The count is crude on purpose, because every more sophisticated metric people propose is one nobody actually collects.

Getting the number

Count, per object: active record-triggered flows, Apex triggers, remaining workflow rules and process builders, validation rules, and roll-up summary fields. Include managed package automation you can see, and note it separately.

SELECT Label, ProcessType, TriggerType, TriggerObjectOrEventLabel
FROM FlowDefinitionView
WHERE IsActive = true AND TriggerObjectOrEventLabel != null
ORDER BY TriggerObjectOrEventLabel

Add triggers from the Apex Triggers setup page and validation rules from Object Manager. It is twenty minutes of work and it is the most informative twenty minutes available to you on an org you have just inherited.

The three bands

Density The actual problem What to do
Under 15 Nobody knows what exists Document and name properly. Do not consolidate.
15–30 Ordering and duplication Consolidate per object; one tool per object.
Over 30 The object is doing too many jobs Split the model, or move work out of the save path.

Under 15: leave it alone

At this density the transaction is not the problem — discoverability is. The cost you are paying is the hour somebody spends finding which of nine flows sets a field, and the fix is naming and description fields, not restructuring.

A naming convention that carries object, timing and purpose, Opp_AfterSave_SetRenewalDate, pays for itself immediately. Consolidating at this density creates risk and returns almost nothing.

15 to 30: consolidate, carefully

Here the interactions start to matter. Two automations write the same field, an ordering dependency exists that nobody chose, and save times are noticeably worse than on comparable objects.

Consolidation is the right move, done one automation at a time with the old one deactivated rather than deleted. Expect it to surface at least one behaviour nobody could explain, and treat finding it as the main deliverable.

Over 30: consolidation is the wrong tool

Merging thirty automations gives you one enormous flow, which is worse than thirty small ones because at least the small ones could be understood individually. At this density the object itself is the problem.

The questions that actually help:

  • Is this object modelling more than one thing? An Account carrying customer, partner, prospect and internal-entity behaviour usually wants separate record types with separate automation, or separate objects.
  • How much of this needs to be synchronous? Audit trails, notifications, integrations and score recalculations rarely do. Moving them to platform events or scheduled work removes them from the save path without deleting anything.
  • How much is dead? On an object with thirty automations, in my experience several are for processes that ended years ago. Check LastModifiedDate and ask the owner.

The number is a signal, not a target

Two failure modes come from taking this too literally.

Gaming it. Merging four clear flows into one branching monster reduces the count and increases the maintenance cost. The count is a proxy for comprehensibility, and a proxy you optimise directly stops being a proxy.

Ignoring what the automations do. Twelve automations that each write to a different object is a far heavier transaction than twenty-five that each set a field on $Record. If the count says 12 and the save takes four seconds, believe the save.

So use the count to decide where to look, then read a FINEST debug log to decide what to do. The log tells you cost. The count tells you where to spend your attention.

Measuring the thing the count is a proxy for

Save one record with Apex Code at FINEST and read CUMULATIVE_LIMIT_USAGE. Three numbers matter: SOQL queries used of 100, DML statements of 150, and CPU of 10,000 ms. Record them per object, and re-record after any change.

A rule of thumb I would defend: if a single-record save spends more than about a quarter of the CPU budget, the object cannot absorb a bulk load of 200 without risk, and you are one data import away from an incident.

Frequently asked

Do validation rules really count?

Include them. They run on every save and they participate in the ordering. They are cheap individually, which is exactly why orgs accumulate forty of them without noticing.

Should managed package automation count toward my band?

Note it separately. It counts toward the transaction’s cost and it is not yours to consolidate, so folding it into the number makes the number less actionable.

What if one object is at 40 and everything else is at 3?

That is the normal shape. Orgs concentrate automation on Account, Opportunity and Case. Work on the outlier and ignore the rest.

Is there a supported report for this?

Salesforce Optimizer surfaces some of it, and the Flow list view can be filtered by object. Neither gives you a single per-object count across all automation types, which is why the manual inventory is still worth doing once.

How often should the count be re-taken?

Once a release for the top three objects is enough. The value is in the trend. An object moving from 12 to 19 in two quarters is the signal, not the absolute figure.

Reference: Triggers and Order of Execution and Debug Log Levels, Salesforce Apex Developer Guide; Salesforce Optimizer, Salesforce Help.