See what your org actually is, process by process

Most org-analysis tools count metadata components. A component has no owner and no budget; a business process — one object, one record type — has both. The analysis leg of Stood Flows reads the estate in the order the questions come: which processes still live at all, which custom and related objects hang off them and at what weight, what their structure costs to understand, and what the code underneath actually ran. In the five-org demonstration portfolio used throughout this page, that is 254 business processes, of which 126 showed no activity in the analysis period and 47 hold no records at all. Illustrative figures from a synthetic estate, not customer results — but until you can see a process as a structure, you cannot say which parts of it are real.

Processes, volumes and stages

Which processes are real, and where the work actually sits, is the first thing a simplification plan needs. The map answers it directly: each business process laid out as its stages in sequence, with everything that acts on it attached to the place where it acts. Each stage carries an active/total count, so you can see where records actually sit, not where the design assumes they flow. Triggered flows appear as nodes connected to the stage they fire on. Validation rules are grouped alongside, each with the condition it enforces. Every record type shows its record count, so a process carrying eleven records is visibly not the same animal as one carrying 36,000.

Take the Concierge Intake Case process from the demonstration estate’s flagship org. Seven working stages, New through Closed, plus an Invalid terminal state. The counts tell the real story: 32,768 of 36,492 records sit in New. In Progress holds zero. Two mid-pipeline stages hold 2 and 3 records respectively. 392 records ended in Invalid. Structurally, this is a seven-stage process. Functionally, it is two: records enter New and, if they move at all, arrive at Closed. Everything in between is scaffolding — including the triggered flows and validation rules attached to stages nothing passes through. Each of those is maintenance surface, upgrade risk and onboarding confusion, spent on stages the business does not use.

The volume columns separate total records from ghost records — records whose stage value no longer exists in the picklist definition, invisible to every list view, process and report grouping, yet present and counted (full definition). In the flagship org’s KPI totals row: 2,721,733 ghosts against 17,643,827 backbone records. And the table is honest about what it has not measured: a process with no records is marked zero-record; a process whose records simply were not touched inside the window is marked “no usage in period” — a different state, with a different meaning.

Related and custom objects: the extremes are the finding

Structure is not only stages and rules — it is what hangs off the process. Most of an org’s data weight sits outside the backbone, in the custom and related objects orbiting each business process, and the KPI matrix shows them per record type with their volumes beside them. The extremes are what to question, and both remedies are process decisions rather than code decisions. Related objects with unbalanced weight at the low end mean a relationship built and never filled in: the initial setup is no longer relevant, and someone can say so. At the high end the volume is usually machine-written debris — an integration logging every sync attempt, a survey tool storing every response and reminder. Around the flagship org’s 17.6 million backbone records sit 108,576,580 related records — better than six to one, and that is where storage bills, slow queries and migration estimates actually live. It is routinely several times the number anyone quotes in a steering committee.

Structure and complexity

What a structure costs to understand — and to maintain, test and one day untangle — is stated as a number. Every business process gets a complexity score built from seven counted inputs — stages, profiles, layouts, lightning pages, validation and assignment rules, triggered flows, and Apex triggers — shown as raw counts in their own columns, next to the score. The score is a plain unweighted sum you can recompute yourself; the methodology page publishes the full definition, the arithmetic and its limits. In the flagship org, Opportunity scores 149 (35 stages, 55 profiles, 42 pages), Lead scores 59 (14 stages, 29 profiles).

The row that makes the whole argument is Eco Loyalty Booking: complexity 22, on eleven records. That is a fully-built process — stages, profiles, layouts, its own automation — serving a volume you could manage in a spreadsheet. No aggregate org-health score would ever surface it. A per-process table does, in one line.

Processes rarely mean anything in isolation, so the table segments them with tags — region labels such as Americas and Asia, tier labels such as Luxury — and filters by object. A regional director can read their own slice; a platform owner can compare tiers.

Code and executions: from trigger to tree

Nobody inherits documentation. In the flagship org you inherit 1,150 Apex classes and roughly 1,010,000 lines of org-wide code written by people who have left, and a standing instruction not to break Opportunity. The Apex view opens with a toggle — Backbone (the code reachable from triggers on your business objects) or Org-wide — and a per-object breakdown: triggers, dependencies, size in characters. Account carries 1 trigger, 12 dependencies, 6,098 characters; Case 1/15/7,297; Opportunity 1 trigger, 21 dependencies, 13,275 characters — one trigger, but the heaviest tree in the org.

Each trigger gets a card — the events it registers, its dependency count, its total characters — and below it the tree expands. Every node is a class, annotated with direct and transitive dependency counts and size, plus tags for what it carries: RT where it branches on record type conditions, DML where it writes, SOQL where it queries. Shared classes appear where they are shared — MER_TriggerDispatcher sits under every trigger, so the dispatcher pattern the original team built is visible as structure rather than tribal knowledge.

Click a class and the right panel answers the questions you would otherwise answer by reading source in another window: the record type conditions that gate the logic, the DML operations listed as operation plus object (insert → Survey__c), the SOQL queries, and the source code itself with the DML statement highlighted. Every tag on every node resolves to a line of Apex you can read on the spot.

Cold classes, ranked by weight

A cold class is one with no observed execution in the event log files for the period analysed. Audits relate to specific periods, and Stood Flows states the period on the figure: the claim is about what ran, not about what might. In the flagship org, 380 cold classes of the 1,150 present — 33% — across a two-week window. The figure is factual, read from the org’s own logs, and it hurts: it is the technical debt.

The accretion chart beside it counts a different thing, and the difference is the argument. It counts classes created — 1,150 of them between 2017 and 2026 — and it ends at the same number the org holds today, because in nine years nothing was ever removed. Created, cumulative; present, now: one number, because the line only ever goes up.

What your own logs can support is a property of your org, not of Stood Flows. Event log file retention and the hourly detail behind it are licensed on the Salesforce side — Event Monitoring, typically through Shield — so how far back the execution, usage and I/O analysis can look depends on the org’s own options. A Quickstart answers it in the first hour, and the scoping call establishes it before anything is promised on it. Structure, complexity and volumes do not depend on it.

The ranking matters as much as the list: candidates rank by dependency weight, not line count. A 4,000-character utility class referenced by nothing is a safe, cheap deletion. A 400-character class with fifteen transitive dependents is a structural decision. When tree work turns into design work, Generate schema artefacts exports the analysed structure in Stood’s sfschema format, documented in the documentation.

In and out: the traffic

The architecture diagram says what should call the org; the logs say what does. The same event log files record the org’s real traffic: the heaviest inbound and outbound requests and the API consumption behind them, ranked over a stated window. The finding is concentration — a few callers usually account for most of the volume, and the set rarely matches the architecture diagram. Integrations added per project are never retired per project; the I/O view is where they surface.

An extraction or simplification decision needs all of this at once: the map tells you what is real, the score tells you what the structure costs, the volumes tell you what the data does, and the tree tells you what the code would drag with it. Stood Flows puts them in the same graph — read-only, with no cloud in the path: local by default, shared only through your own GitHub or S3, with roles (how).

Next in the arc: Usage & cost — who actually works in it, and what it costs →

All figures on this page are illustrative, drawn from a synthetic demonstration estate — not customer results or benchmarks. Portfolio figures span the five demonstration orgs; process, Apex and record figures are from the flagship org.