Stood Flows is built around a single observation: every Salesforce org analysis you'll ever do starts from the same handful of standard CRM objects, then radiates outward into automation, code, integrations, and licensing. Trying to look at all of that at once is hopeless. Looking at them in the right order is straightforward.
The app enforces that order through a layered methodology — backbone first, then everything else.
The backbone of a Salesforce org is the set of standard objects that hold the business: Lead, Opportunity, Case, Account, Contact, Campaign. Almost every business process, validation rule, layout, profile permission, automation, and integration ultimately lands on a row in one of those tables.
In Stood Flows, "backbone" is also a configurable concept — the objects panel lets you mark additional custom objects as backbone so they participate in lineage, RT modelling, and lifecycle analysis the same way standard ones do. The default six are seeded for every Salesforce graph.
Why backbone-first?
It bounds the analysis. You don't try to scan 600 custom objects on day one. You start with what matters, and pull custom objects in as you discover them via relationships.
It maps cleanly to how Salesforce thinks. Profiles grant access to objects, layouts assign per record type, record-triggered flows fire per object — they all hang off the backbone.
It gives every later analysis somewhere to anchor. When you look at user activity, integration traffic, or Apex DML targets, you can ask "is this backbone, or is it noise?" and the answer is already on file.
A single click on Refresh pulls the structural skeleton — what record types exist, in what business processes, with what stage volumes. That's intentional: backbone is fast and idempotent; the heavier analyses are opt-in.
The backbone refresh fetches exactly three things:
Picklist statuses and stages for Lead, Opportunity, Case, Campaign — the universe of status / stage values currently configured.
Business processes — the picklist-based process definitions on Lead, Opportunity, Case, Campaign, with stage ordering.
Record types for every enabled object, plus per-record-type record counts per stage. Master totals come from /services/data/limits/recordCount (exact); per-RT counts come from SOQL COUNT(Id) GROUP BY slices and are capped at 10 000 with 10 000+ shown when the cap is hit.
That populates the KPI table's Volumes column group end-to-end.
What backbone does not fetch:
Layouts, FlexiPages (Lightning record pages), profiles + record-type visibilities, validation rules, assignment rules, record-triggered Flows, Apex triggers, custom object relationships — all of those come from Analyze Complexity (Steps 4–7 in the underlying fetch pipeline). They populate the KPI Complexity column group.
Apex bodies, dependency walks, SOQL/DML detection — Analyze APEX (separate, slower step; see Apex doc).
Custom-object volumes and relationships beyond the standard six — Analyze Custom Objects (or auto-included when you Refresh with custom objects enabled in the graph's object config).
User activity (creators/modifiers per RT) — Analyze Usage.
DML / I/O / licensing activity — separate analyses driven by Event Log Files.
The output is a version snapshot at workspaces/<alias>/graphs/<slug>/versions/v<N>.json containing the backbone reads plus whatever earlier analyses you opted to carry forward (see "Keep analyses" in the Refresh confirmation).
The KPI table is the master view of a version. One row per (object, record type, business process) triple, with column groups for Volumes (always populated by refresh) and Complexity / Objects / APEX / Usage (each populated by its own Launch X analysis button in the column-group header).
Backbone gives you the structure. Phase-2 analyses give you the behaviour:
Analysis | Question it answers | How to launch it | Where to find it |
Complexity | How heavy is this process? | KPI tab → click the | KPI tab → Complexity columns + the complexity doc |
Custom Objects | What custom objects hang off the backbone and how big are they? | KPI tab → | KPI tab → Objects column group + the objects doc |
APEX | What classes / methods / DML do the triggers pull in? | KPI tab → | KPI tab → APEX columns + dedicated Apex panel |
Usage | Across the analysed window, which users acted on which record types? | KPI tab → | KPI tab → Usage columns (Modifiers, Creators, Actors) |
Lifecycle | Where do records get stuck, and for how long? | Same modal as Analyze Usage, "Include lifecycle" checkbox | KPI tab → Lifecycle columns |
Licensing | What are we paying for and who's using it? | Licensing tab — runs at panel open | |
DML | Who is actually creating / modifying records? | Licensing tab → DML sub-tab → date-range run | |
I/O | Who talks to this org from outside, and where does this org call? | I/O tab → Analyze button |
Each phase-2 analysis is launched explicitly — they take time and (for ELF-driven ones) consume the daily Event Log File API budget. Results land in JSON files alongside the version snapshot and the next refresh carries them forward when Keep analyses is ticked.
A version is a backbone snapshot. An analysis is a behavioural overlay computed on top of a version. You can have several versions accumulating in versions/ (every Refresh creates a new one) but at most one current analysis of each type per version. The dropdown next to "Last refresh" in the header switches between versions; analyses follow whichever version is selected.
This separation is what lets you compare "the org last quarter" against "the org now" without losing the deeper analyses you ran on the older snapshot.
Every cell in every analysis can be right-clicked. The menu offers Create issue — the resulting GitHub issue (or local CSV row, see Issues) carries an invisible HTML-comment anchor pointing back at the exact (graph, record type, column, object, name) it came from. Open the issue later and the View button takes you back to the right view, the right filter, and the right row, even after several refreshes. That's how you turn an analysis run into an audit trail that survives time.
For a clean first pass on an unfamiliar org, this is the workflow:
Create a folder for the org, create one graph.
Refresh backbone. Wait for it to finish (≈ 30 s to a few minutes). The KPI table shows Volumes only at this point.
Look at Volumes — does the row count distribution match what you expected? Spot the obvious dead RTs (zero volume) and the obvious hotspots.
Launch Complexity analysis from the + Complexity ▾ header. The KPI Complexity columns fill in — sort by Score to find heavy (object, RT) cells, tag them.
Launch APEX analysis from the + APEX ▾ header. The Code columns fill; jump to the Apex tab for the heavy triggers.
Launch Usage analysis from the + Usage ▾ header. Modifiers / Creators / Actors columns fill; drill into who.
Open the Licensing tab → DML sub-tab → run for the same window. Bucket users into Active / Low-DML / Pseudo-only / No-DML / Integration.
Open the I/O tab and run inbound + outbound analyses. Spot heavy consumers and runaway callouts.
Anchor issues on anything that surprises you.
That's it. Each step gives you the input the next one needs.