Diagnostics with named remedies

A diagnostic is a recurring finding with a name: a pattern of bloat that shows up in estate after estate, detected the same way each time, remedied the same way each time. It is not a severity label and not a grade. Stood Flows surfaces the insight; the diagnostic is the shape an analyst — or an agentic co-worker — recognises in it and raises as an issue. Naming the pattern matters because unnamed bloat has no owner — a diagnostic gives a finding a detection method and a remedy someone can be asked to execute. Two things hold for every entry below. First, this is an entry set, not a catalog: diagnostics are added as new signals prove useful in real estates — a pattern has to recur, detect reliably and carry a workable remedy before it earns a name. Second, a finding is a question put to the org’s owners, never a verdict passed on them.

An entry set, not a fixed catalog — it grows as new signals prove useful in the field.

How any finding is qualified

Every finding below goes through the same three-part test before it becomes a work item. Business value: what does the process, code, seat or data actually contribute? A zero-record process launching next quarter and one abandoned in 2019 read identically in the data; only an owner can tell them apart. Technical constraint: what would the remedy drag with it — the integrations, managed packages and dependency trees that make one deletion an afternoon and another a project? Job weight: what does the remedy cost to execute, so the worklist can be ordered by return? Three outcomes follow. Some findings trigger immediate cleanup — cheap, safe, done this sprint. Some become a line in a transformation programme: real work, scheduled deliberately, evidenced snapshot over snapshot. And some are legitimately kept — a seasonal process, a load-bearing dispatcher, a retention obligation — and documented as such, so the flag stops recurring as a question. This test is stated once here; it applies to all eight diagnostics that follow.

Zero-record record types

A zero-record business process is one object combined with one record type, fully built — stages, profiles, layouts, lightning pages — with not a single record in it. Not quiet, not seasonal: empty. In the five-org demonstration portfolio, 47 of 254 business processes are zero-record. They are created deliberately and abandoned quietly: a cancelled launch, a regional variant cloned for a market that never opened, a migration staging type that never went live. Nobody removes them because removal earns no credit and the creator has usually left. Detection is arithmetic, not inference: in the KPIs table the Total column reads zero for the row, and the Mapping view renders the full swimlane — stages, attached triggered flows — with a record count chip of 0. The dashboard’s PROCESSES card tracks the count over snapshots; it humped at 74 as new processes launched empty, then fell as they filled or got cleaned. While each one stays, it carries its full structural weight into the complexity score and remains a swimlane every architect must read past — a standing tax on understanding the org.

Zero and low-activity processes

A no-activity business process saw no record created or modified during the analysis window. It differs from a zero-record process: it may hold millions of records — an archive, a completed migration, last year’s campaign structure — but nothing moved. The demonstration portfolio flags 126 of its 254 business processes against a roughly 90-day window: half the structure being maintained, tested and paid for produced no measurable work in a quarter. Processes stop being used long before anyone declares them dead — a superseded record type kept for history, a sold product line whose pipeline stays, a pilot that ended without a decision — because decommissioning requires an assertion nobody can make from Setup. Stood Flows marks inactive rows in the KPIs table as “no usage in period”, with the date range stated, and can re-run the usage analysis to add the date of the last record ever created; the dashboard carries No activity as a tracked sub-metric with its window printed on the card. Check the window before concluding — a quarterly process looks dead in a short one. While flagged processes stay, their full complexity remains in scope for every release regression and security review.

Ghost records

A ghost record’s stage value no longer exists in the picklist definition: it appears in no list view, no process, no report grouping — yet it exists, counts and consumes storage. The demonstration estate’s flagship org holds 2.6 million ghosts against 17.6 million backbone records: roughly one record in seven that no stage report or forecast will ever surface. Ghosts are made whenever data and structure move at different speeds: a picklist value retired without migrating the records sitting on it, a stage renamed while an integration keeps writing the old string through the API, a bulk import whose source statuses were never mapped. Nobody removes them because nobody sees them — that is the definition. The KPIs table carries a Ghosts column beside Total on every business process row, so the count sits next to its denominator; the dashboard’s BACKBONE RECORDS card tracks the trend across snapshots, which matters because a growing ghost count means something is still writing unknown values today. While they stay, every stage-based report undercounts, each migration inherits them, and millions of invisible rows slow every full-object query.

Stage and status equilibrium

This diagnostic reads a business process’s stage structure and its record distribution as one finding. The structural half is the picklist: values whose counts no longer justify them. The behavioural half is the distribution’s shape, with two failure modes. The bottleneck: one stage holds nearly everything — 32,768 of 36,492 records resting in New, in the demonstration org’s Concierge Intake Case process. The pass-through: a stage records transit but never occupancy — 0 of 36,492 on the stage after it. Stages accrete one reorganisation at a time; each addition has a sponsor and removal has none, while automation and user shortcuts drift the distribution on their own. The whole shape is visible to nobody working inside the process — which is why the Mapping view draws it: every stage box carries its load as active/total, terminal states distinguished, triggered flows attached to the stages they fire on. The KPIs table’s per-stage columns sort the same counts across the estate. While it stays, stage-based forecasts describe a process that does not exist, and the pile-up hides real aging: a warehoused New stage is where missed cases go to be found late.

Profile visibility sprawl

Visibility sprawl is a business process exposed to far more profiles than the people who operate it. Profiles are one of the seven counted inputs to the complexity score, and often the heaviest: the demonstration org’s Opportunity process is visible to 55 profiles and scores 149; Lead, at 29 profiles, scores 59; the flagship org carries 255 profiles in all. Sprawl accumulates because visibility is granted at launch and never withdrawn — new profiles cloned from wide templates inherit record-type access nobody chose, project teams grant “to be safe” because a missing permission generates a ticket and an excess one generates silence, and removal risks breaking someone visibly while leaving it costs nothing anyone can see. In the KPIs table, the COMPLEXITY detail toggle puts a Profiles count beside the score for every process; the telling signal is the gap between that count and the Actors column — how many profiles can see the process versus how many people actually touched its records. While it stays, every visible profile is a layout assignment to maintain, a widened audit scope, and seat exposure the licensing analysis must later explain away.

Related custom objects

Related custom objects are the non-business objects orbiting the backbone — logging objects, survey responses, sync-state rows, per-interaction detail — that hold most of the org’s actual data weight. In the demonstration estate’s flagship org: 17.6 million backbone records, and 108.5 million related records around them — better than six to one. None of these objects is a business process — no stage, no pipeline, no owner — so their volume goes unexamined. They are almost always written by machines: an integration logging every sync attempt, a survey tool storing each response and reminder, a managed package journalling its own activity. Growth is linear and silent; insert-only objects never trigger the complaints that make humans look. The KPIs table carries an OBJECTS column group per business process — volume, lookups, related — and the extremes are what to question: near-zero volumes mean a relationship built and never adopted, extreme volumes are usually log or integration debris. The dashboard states Related as a headline sub-metric, up 7% in the demonstration quarter. While it stays, it is the storage bill, the backup window, the sandbox copy — and a growth rate that compounds.

Apex dependencies and cold classes

Two findings decide most of a code cleanup: the branches too heavy to change safely, and the classes nothing runs. Stood Flows reads the org’s code the way the runtime does — from each backbone trigger, down through everything it can reach. In the demonstration org, the Opportunity trigger carries 21 dependencies and roughly 13,000 characters against 9 to 15 elsewhere; and 380 of the 1,150 Apex classes present are cold — 33%, with no observed execution in the event log files over a two-week window. Audits relate to specific periods, and the period is stated on the figure. Apex accumulates because it outlives its callers: a class loses its last live reference in a refactor and stays, because deleting code feels riskier than keeping it, while the busiest object collects every project’s logic. The Apex view expands each trigger into its dependency tree — every node sized, tagged for record-type conditions, DML and SOQL, with the actual source a panel away — and shared nodes read as shared, so a load-bearing dispatcher is not mistaken for debris. While it stays, every release tests and deploys code nothing runs, and the heaviest branch sets the change cost for the busiest object.

Integration and I/O suspects

An integration suspect is a user account whose write behaviour matches a machine signature rather than a human one — volume, timing, object mix. The flag is a heuristic and the product says so: it exists so machine accounts are not misread as idle humans. The demonstration estate’s flagship org flags 35 among 2,482 assigned named licenses, beside the users writing only to excluded objects and those writing nothing at all. Integrations end up on human licenses through expedience — middleware credentials issued on a Friday, a departed admin’s account still running its scheduled jobs — and the traffic accretes the same way, added per project and never retired per project. The Licensing view analyses write behaviour by license, object or package over a stated event-log window, with integration patterns applied; the I/O view, built on the same event log files, ranks the heaviest inbound and outbound traffic — and the finding there is concentration: a small set of callers accounts for most of the volume, and that set rarely matches the architecture diagram. While it stays, each misfiled integration occupies a seat priced for a person, pollutes every human metric downstream, and becomes an account nobody can explain at renewal.

Where to go deeper

The complexity score these findings feed is the plain sum of seven counts — stages, profiles, layouts, pages, flows, triggers, rules — with no weighting and no black box; the methodology page walks through it and shows how to audit it against your own Setup. For detection detail beyond what a website should carry — exact columns, windows, options — the documentation at flows.stoodcrm.com is the reference. And if your estate produces a recurring pattern you think belongs in this set, tell us: that is how the set grows.

All figures are illustrative, drawn from a synthetic five-org demonstration estate — not customer results or benchmarks.