The KPI tab is the master view of a backbone version. One row per (Object, Record Type, Business Process) triple plus a master row per object. Columns are grouped — you toggle whole groups on and off with the buttons above the table.
The intent isn't to read the whole table in one go. It's to scan a column group, sort by a heavy column, and drill into the outliers.
Column | What it is |
Process | Business process label (the picklist-based grouping on Lead/Opportunity/Case/Campaign) or "—" if the row has no BP. |
Object | Object label, with a colour badge for the type. Master rows say "Object Total". |
Record Type | Developer name + display name. Master rows show "(all)". |
Tags | Free-text tags you've added. Click the cell to add or remove. Tags survive refreshes and are searchable. |
These three never scroll. Everything to the right of Tags is scrollable.
Toggle group: Volumes.
Column | What it is |
Total | Total record count. Master rows: from |
Ghosts | Records that ended up in a "final-negative" status (e.g. Disqualified, Closed Lost, Junk). Configurable per object in graph settings. |
Active | Total − Ghosts. The "real" active records. |
s0 … s4 | One column per stage in the business process picklist order. Counts of rows currently in that stage. Useful for spotting funnels where everything is stuck before the finish. |
If a row has no business process, the s-columns are blank.
See Volumes and complexity for how to use these.
Toggle group: Complexity. Filled by the Launch Complexity analysis action — click the + Complexity ▾ header (or Complexity ▾ after the first run, where the menu offers Re-run Complexity analysis). The underlying fetch pulls profiles + record-type visibilities, layouts, FlexiPages (Lightning record pages), record-triggered Flows, Apex triggers, validation rules, and assignment rules. None of those are pulled by a plain Refresh — that keeps backbone refreshes fast.
Column | What it is |
Score | Single integer: stages + profiles + layouts + Lightning pages + record-triggered flows + Apex triggers + validation rules + assignment rules. Higher = more moving parts for this (object, RT). |
Stages | Stage count from the business process. |
Profiles | Number of profiles that have this record type assigned. |
Layouts | Distinct page layouts in use for this RT across profiles. |
Pages | Distinct FlexiPages (Lightning record pages) wired up. |
Flows | Record-triggered flows whose entry criteria evaluate against this RT. |
Triggers | Apex triggers on the object whose RT-conditioned code touches this RT (detected from the trigger body — see Apex doc). |
Rules | Validation rules + assignment rules combined. |
Sort by Score descending to find the (object, RT) cells that absorb the most maintenance effort. You'll typically discover three categories: legitimate big processes, abandoned RTs that haven't been retired, and one or two cells where complexity grew quietly and nobody noticed.
Toggle group: Custom Objects. Visible only when custom objects with volume have been pulled in.
Column | What it is |
Objects | Number of related custom objects with non-zero row counts, reachable from this (object, RT) via lookup or master-detail. |
Items | Total related items for the standard child objects (OpportunityLineItem under Opportunity, CampaignMember under Campaign). |
One column per CO | Per-custom-object volume in this row's scope. The header carries 🔗 (lookup-related) or ⇄ (master-detail) and the CO label. |
This is where the "long tail of objects" becomes legible: a single Opportunity RT might be the entry point for 30 custom child objects representing line items, attachments, audit logs, etc. You see them all in one row.
Toggle group: Code. Filled by the Analyze Code button — a separate analysis pass.
Column | What it is |
Classes | Number of Apex classes transitively reachable from triggers on this object. |
Methods | Method count across those classes. |
Deps | Dependency edges (class → class) in the reachable graph. |
Size | Total Apex source size (characters, comments stripped) of the reachable code. |
Pair this with the Apex tab: a tiny trigger that pulls in 80 classes and 200k characters of code is a maintenance black hole.
Toggle group: Usage. Filled by the Analyze Usage button. Reads from the last N days of CreatedDate / LastModifiedDate / CompletedDate on each (object, RT).
Column | What it is |
Modified | Count of records last-modified in the analysis window. |
Created | Count of records created in the window. |
Modifiers | Distinct users who modified at least one record. |
Creators | Distinct users who created at least one record. |
Actors | Distinct users who appear as either modifier or creator (the union). |
Activities | Closed Tasks in the window for this (object, RT). |
These numbers are what feed the Actors column on the Licensing → Profiles tab — see Licensing. Inactive RTs show 0s here, which is the strongest signal that an RT can be retired.
Click any column header to sort.
Right-click any cell for the context menu (Create issue, View in Apex, etc.).
The Export button on each tab writes a CSV of the current view, including hidden column groups.
The KPI auto-export — a latest-kpis.csv next to the version JSON — is written every time the KPI table re-computes after a Refresh or analysis. That's the "snapshot of the snapshot" you can hand to an auditor without opening the app.
A master row (Object Total) sums its RT rows where the maths makes sense. Total is real (independent count, not the sum, because RT rows are capped at 10k). Modified / Created / Actors are sums. Complexity components are not summed — a profile that's visible on three RTs counts once at the master level.
When master totals look smaller than the sum of RT rows, it's the 10k cap — drill into the master to see "10 000+" for the capped RTs.