These two columns groups are the cheapest way to find what's worth investigating in an unfamiliar org.
A volume row tells you how big a slice of the database is. Read it top-down, then RT-by-RT.
For every enabled object, Stood Flows queries /services/data/limits/recordCount. This returns exact totals fast and without scanning rows — the same numbers Salesforce uses for storage planning. Master row's Total is taken from here.
For each record type, Stood Flows runs a SOQL SELECT count(Id) FROM <object> WHERE RecordTypeId = '<id>'. SOQL count queries are capped server-side at 10 000 rows for some configurations and timed-out for huge per-RT slices; rather than fight that, Stood Flows uses a 10 000 ceiling and displays 10 000+ when the count hits the cap. For tables above a few million rows the per-RT row goes straight to 10 000+ to avoid the timeout altogether.
Each business process has a notion of "final-negative" stages — Lost Opportunities, Disqualified Leads, Junk leads, Closed Cancelled cases. Stood Flows lets you mark those stage names per object (graph settings → Lead Final Negative Statuses, etc.). Once marked, the Ghosts column counts records currently in those stages; Active is Total − Ghosts.
Why this matters: most orgs sit on years of Lost Opportunities and Junk Leads. They distort every per-stage average, drag down sales analytics, and inflate the licensing equation. Splitting Active vs Ghost in the KPI table lets you ask "do these ghosts need archiving?" without running a separate report.
When a row has a business process, the columns s0…s4 are filled in stage order (matching the picklist sortOrder). The headers carry the stage label on hover. A row with most volume sitting in s0 is a funnel that converts poorly; a row that explodes in s2 is a stuck pipeline.
This is where you spot the "we have 80 000 leads in New status that nobody touched in 18 months" kind of issue — open the row, click into the stage, hand the count to whoever owns lead routing.
Each (object, record type) row gets a single integer Score. It's the sum of the artefacts that the platform binds to that scope:
Score = stages+ profiles (count of profiles with this RT visible)+ layouts (distinct page layouts for this RT)+ pages (distinct FlexiPages for this RT)+ flows (record-triggered flows that match this RT)+ triggers (Apex triggers with RT-conditioned code for this RT)+ rules (validation + assignment rules in scope)
There is no weighting and no normalisation. We want the score to be obvious — read the breakdown and you know exactly where the number came from. A row with Score = 38 is a row where 38 distinct artefacts touch that one (object, RT). That's a lot of moving parts to keep aligned when the process changes.
The KPI table shows just Score by default. Tick the Detail option above the table to expand into the per-component columns. Two practical patterns:
High Profiles, low everything else: that RT is highly visible but lightly automated. Probably a read-mostly view. Maybe the visibility is over-broad.
High Flows + Triggers + Rules, low Profiles: heavily automated process with narrow access. Common for back-office RTs. Often the most fragile cells in the org — touching them breaks behaviour for the small audience that depends on it.
It's not a quality metric. A score of 50 isn't "bad". A score of 5 isn't "good". It's a "how much surface area is in play" gauge.
It's not weighted by record volume. A trivial RT with no records can have a complexity of 30 if it has 30 profile visibilities. Pair with the Volume columns.
It's not stable across releases when new artefacts are added. Adding a new FlexiPage bumps every score that touches it. The trend over multiple versions tells you whether the org is accumulating complexity faster than it's retiring it.
Complexity is not populated by Refresh — it's its own analysis pass, launched from the KPI table itself. Click the + Complexity ▾ header above the column group; the dropdown offers Launch Complexity analysis (first time) or Re-run Complexity analysis (subsequent runs). The fetch pulls profiles + RT visibilities, layouts, FlexiPages, record-triggered Flows, Apex triggers, validation rules, and assignment rules in one go, then computes the score per (object, RT).
The result is persisted in the version JSON. When you next Refresh with Keep analyses ticked, the complexity fields are carried forward into the new version snapshot — so you only need to re-run Complexity when something materially changed in the org's configuration (a new layout, new flow, new profile), not on every refresh.
The simplest practical drill:
Sort the KPI table by Complexity Score descending.
For each high-score row, look at its Volume group:
High complexity + high active volume → real business hotspot. Worth a deeper audit (Apex tab, Licensing tab) and probably an issue.
High complexity + low active volume / high ghosts → over-engineered for a dead RT. Candidate for retirement.
High complexity + zero usage (check the Usage columns too) → likely an RT that was deprecated functionally but never cleaned up.
Tag each row with audit, retire, keep-as-is, etc., as you triage. The tags survive refreshes.
The combination of volume + complexity is the cheapest, most reliable starting point for an org audit. Everything else in the app drills further down into specific causes.