The folder Dashboard shows eight cards. This page defines every figure on them, in one line each, and closes each section with how to read it.
Scope chips — Global sums the selected orgs; each org chip shows that org alone.
Baseline — the Δ next to every figure compares the latest snapshot with the baseline you pick: previous snapshot, ~1 month, ~3 months, or the first one ever captured. Green means the figure moved in the healthy direction, red the opposite, grey means no judgement.
Global deltas — the headline value sums every selected org, but the Δ only counts orgs that actually have an earlier snapshot, so an org with no history never shows up as growth.
Click a card to expand it: full evolution curves per sub-KPI, plus a bar per org for the latest values. Clicking an org there opens that org on the matching analysis.
⭳ Export PDF prints the same eight cards, same order, same arithmetic.
Total — the number of business processes in the org: every backbone object × record type, counted once each (standard backbone objects plus the custom objects you enabled).
No activity — processes with no record created or modified anywhere in the analysed usage window.
Zero-record — processes holding no records at all.
How to read it. Total is the width of your business model — how many distinct paths the org asks people to follow. The other two are the dead weight inside it: Zero-record processes were never used, No-activity ones were used once and abandoned. A healthy org grows Total slowly and keeps the two dead counters flat or falling. When they climb faster than Total, configuration is accumulating faster than the business is actually using it, and every one of those processes still costs training, reporting and maintenance.
Backbone records — total records across the backbone objects (standard plus the custom objects you enabled).
Ghost — records still sitting in a stage or status that no longer exists in the object's current picklist.
Related — total records across the related child custom objects.
How to read it. This is data mass, and mass is what makes an org slow, expensive to migrate and hard to report on. Backbone records should track business activity; if it grows much faster, something is duplicating or importing. Ghost is the clearest quality signal on the page — those records fell out of the process when someone edited a picklist, so no report or automation reaches them any more. Related growing far faster than Backbone usually means one child object has become a log rather than business data.
Score — the org's total automation complexity, summed over every flow.
Flows — the total number of flows in the org's metadata.
Profiles — the total number of profiles.
How to read it. Score is the effort to change anything: two orgs with the same number of flows can differ several-fold, because one has a few large tangled flows and the other many small clean ones. Read Score against Flows — Score rising while Flows stays flat means existing automation is getting heavier, which is the harder problem to unwind. Profiles is the access-side equivalent: each one is a permission surface someone has to keep correct, and the count only ever grows unless it is deliberately consolidated.
Total classes — every Apex class in the org, not only the ones reached from the backbone.
Org-wide LOC — total lines of Apex code.
Cold classes — classes with no recorded runtime execution in the analysed period.
How to read it. Total classes and LOC are the size of the custom-code estate you own — the part of the org no configuration change can simplify. Cold classes is the actionable one: code that never ran during the period is either dead, seasonal, or only reachable by a path nobody uses. A large cold share is good news, not bad — it is the safest place to start reducing the estate. Watch LOC per class over time: rising LOC with flat class count means classes are growing instead of being split.
Total — provisioned seats on the valued licence types only (Salesforce, Salesforce Platform, Salesforce Integration); login-based and community licences are deliberately excluded.
Assigned — how many of those seats are attached to a user.
Buffer — Total − Assigned: seats you pay for that nobody holds.
Login 30d — users on those licences who logged in within 30 days of the snapshot.
Active DML — named users who actually created or changed data in the analysed period, not merely logged in.
How to read it. Read the four figures as a funnel: paid → assigned → logging in → doing work. Buffer is contractual headroom, not waste — a little is healthy for onboarding, a lot is money parked. The interesting gaps are the later ones: Assigned far above Login 30d means seats held by people who left or never started; Login 30d far above Active DML means people who open the org but do their real work elsewhere. That last gap is usually where a licence tier can be downgraded rather than removed.
Connected (mo.) — distinct internal named users who logged in at least once during the latest complete month.
Daily — of those, users active on 20 or more days in the trailing 28 (about every working day).
Weekly — users active on 4 to 19 days in the trailing 28.
Others — the remaining connected users: monthly and occasional, grouped together.
How to read it. Connected tells you reach, the tiers tell you depth — and depth is what predicts whether the org is load-bearing for a team. A large Others tier against a small Daily one is a reporting-only population: they visit to look something up, so training, adoption pushes and new features barely land. Growth is most meaningful when it moves users up a tier rather than only adding new names. The tiers are grouped as three rather than four on purpose, so the read stays reliable even on orgs with a short login history.
Connected (mo.) — distinct community and other external users who logged in at least once during the latest complete month.
Daily — of those, users active on 20 or more days in the trailing 28.
Weekly — users active on 4 to 19 days in the trailing 28.
Others — the remaining connected external users: monthly and occasional.
How to read it. Same tiers, a different population and a different economics: community and portal licences are usually priced per login or in large blocks, so the number that matters is how many of the provisioned users ever show up. Compare this card with the named one — an external population much larger than the internal one is normal for a portal, but Daily near zero means the portal is a destination people are sent to once rather than a channel they work in. Movement here is the cleanest measure of whether an external-facing rollout took.
Reported — total issues logged against the org.
Open — issues not yet resolved.
Resolved — issues closed.
How to read it. This is the only card you fill in yourselves, and it is what turns the other seven into a work record: everything else describes the org, this describes what you decided to do about it. Read Open as the live backlog and Resolved as throughput — Reported rising with Open flat means the team is keeping pace, while Open rising means findings are accumulating faster than they are being cleared. Over several snapshots the pair also shows whether the analysis is being acted on at all, which is usually the first question a sponsor asks.