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: 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). |
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. When a record type had no activity in the window, the row no longer just shows zeros — it tells you when that type was last used (“last record created …”), or says “No records for this type” when it has never held a record. That makes a long-dormant record type easy to tell apart from one that was simply quiet this period.
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. |
Activities | Related activity records (Tasks) for this (object, RT). |
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.
A per-CO cell normally shows the exact count. It shows a "+" instead only when the related object is very large (≈300 000+ rows) and the precise per-record-type count was skipped to keep the refresh fast. Click the "+" to run Fetch object volumes, which counts it on demand and replaces the "+" with the real number.
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 | The single complexity number for this (object, record type): the sum of every component to the right. It is a count of the things attached to the process, not a weighted formula, so it is easy to justify. Higher = more moving parts, so more expensive and riskier to change. |
Stages | How many steps the business process has. A longer process is more to configure — and more places a record can stall on its way to done. |
Profiles | How many user profiles can actually see and work with this record type — i.e. the blast radius of a change. "Visible" means a profile can read records of this record type, whether through a record-type visibility or through object read access (including access granted via a permission set). Only real, in-use profiles count (they must have active users and a page layout). A process 40 profiles can touch is far riskier to change than one only 2 can. Only profiles with a user active in the last 30 days are counted, so dormant profiles don't inflate the number; the drill-down offers a simulation that lists every profile that can see the record type regardless of recent activity. |
Layouts | How many distinct page layouts are in play for this record type across those profiles. More layouts means more UI variants that must be kept consistent whenever the process changes. |
Pages | How many Lightning record pages are configured for this object — each one another place the record's screen and on-page logic are defined. |
Flows | How many active record-triggered flows (before- or after-save) fire on this record type — the no-code automation load. Every one runs on each save, so the count is a direct measure of automation weight on the process. |
Triggers | How many active Apex triggers fire on this object, attributed to this record type from the code. Apex is the hardest automation to change safely — it needs tests and a deployment — so triggers are a strong complexity signal. (See Apex doc.) |
Rules | Validation rules + assignment rules on the process. Each is a business constraint that has to stay consistent as the process evolves — quiet sources of "why can't I save this record?" friction. |
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.
Every complexity cell is clickable: clicking the Score or any component opens a drill-down that lists the exact contributing items — the specific profiles, flows, triggers, validation rules, and so on — each openable so you can inspect it or raise an issue against it.
Apex per-object metrics — classes, methods, dependency count and code size — are no longer KPI columns. That analysis now lives in the Apex tab, where you can run it per object or org-wide.
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.