Automation health
I own the flows, triggers, and rules that fire on every record change, and I treat them as production code even when they are declarative. The failure mode is a silent flow failure or a recursion loop that corrupts records for a week before anyone notices, because nothing throws an error a human sees.
Shape of it
6 metrics
- Automation success rate
- Share of automation runs (flows, triggers, scheduled jobs) that complete without error.
- successful runs / total runs
- Example 40,000 flow interviews in a day, 320 fault out silently → 99.2%. Those 320 records skip the update that routing and forecasting read next.
- Benchmark Practitioner SLO 99%+; anything lower and you are corrupting records faster than you can find them
- A silent automation failure leaves records half-processed while every dashboard stays green; success rate is your systems pulse.
- Automations per object
- Count of active automations (flows, triggers, workflow rules, process builders) firing on a single object.
- Example Opportunity carries 34 active automations across flows, one legacy trigger, and three process builders. Order of execution between them is now undefined, which is where the intermittent bugs come from.
- Benchmark Practitioner guidance: consolidate to one record-triggered flow per object per timing (before-save, after-save); 20+ overlapping automations on one object is a red flag
- Stacked automations on one object create order-of-execution races and slow saves; the count is the first read on technical debt.
- Declarative vs code ratio
- Share of automation logic built in declarative tools (Flow) versus Apex code.
- declarative automations / total automations
- Example 82 automations, 68 in Flow and 14 in Apex → 83% declarative. The 14 Apex pieces should each have a reason Flow could not do it, or they are debt.
- Benchmark Salesforce steers declarative-first; practitioner norm is 70-90% declarative, with Apex reserved for bulk, complex logic, or callouts
- Declarative is maintainable by admins and visible in one place; every unnecessary Apex trigger raises the cost of every future change.
- Average save time (CPU time)
- Time consumed processing automation on a record save, against the platform transaction limit.
- Example An owner change on a top account triggers a cascade flow plus a routing package and consumes 9,400 ms of the 10,000 ms limit; one more field update and the save throws a CPU-time exception.
- Benchmark Salesforce Apex CPU limit is 10,000 ms synchronous; practitioner target is to stay well under (e.g. below 5,000 ms) to leave headroom
- Automation quietly eats the transaction budget until a big record or a bulk load blows the limit and saves start failing.
- Error queue depth
- Count of failed automation runs sitting in fault logs, error queues, or paused-flow interviews.
- Example The paused-flow list holds 47 interviews from a scheduled job that hit a null lookup; each is a record stuck mid-update until someone resumes or fixes it.
- Benchmark Practitioner target is zero standing; alert on any growth, since a rising queue means a failure is repeating
- A growing error queue is a failure that is still firing; depth over time tells you whether you are fixing or accumulating.
- Recursion / re-entry rate
- Frequency of automations re-triggering themselves within a single transaction (update loops).
- Example A flow that stamps a rollup on the account fires on account update, which the rollup itself triggers; without a recursion guard it runs 16 times per save and burns CPU for nothing.
- Benchmark Practitioner target near zero; guard with a static flag or entry criteria so a flow does not re-fire on its own field write
- Recursion multiplies CPU cost and can double-write fields; it is the classic cause of intermittent, hard-to-reproduce save failures.
01
02
03
04
05
06