Licensing

The Licensing tab answers two related questions:

1. What are we paying for? — inventory of licences, what's provisioned vs used, how much it costs.

2. Are we actually using what we pay for? — who logs in, who works, who just sits there.

It has three sub-tabs: Licenses, Profiles, DML. The DML sub-tab is the bridge to the DML analysis.

The license inventory (Licenses sub-tab)

Each row is one Salesforce licence type (UserLicense + PermissionSetLicense). Columns:

Add-on licences (PermissionSetLicense — Einstein, CPQ, Salesforce Mobile, etc.) appear below the core list with the same columns.

Pricing entered here drives every dollar figure in the rest of the panel. There's no global price list — you tell the app what you pay for what.

Profiles sub-tab

Each row is one profile within a licence. Profiles roll up under their licence; licences roll up under their bucket.

The three buckets

Stood Flows classifies every licence into one of three buckets:

• Named — fully licensed users with a seat. Salesforce, Salesforce Platform, CRM User, …

• Community Login — community / partner login-pool licences (pooled logins, not per-seat).

• Other — everything else: Identity, Chatter Free, Analytics Cloud Integration, Authenticated Website, etc.

The classification is opinionated and lives in the codebase — it matches how most orgs actually budget. You can see which bucket a licence ended up in next to its name.

Why the buckets matter:

• For Named licences, "Assigned" equals user count: each seat is a real person you pay for.

• For Community Login licences, "Assigned" is pro-rated yearly entitled logins for this analysis period — community logins are a pooled metric, not a per-seat one. A licence with 50 000 entitled logins/year, analysed over a 17-day window, shows ~2 300 as "assigned" for that window.

• Other licences are mostly free or trivially priced; we don't break out cost in detail there.

Profile columns

A note on the Actor $ split:

• The three buckets — Unlogged + Actor $ + Non-actor $ — sum exactly to Assigned.

• The math accounts for API-only actors: users that produce DML but never log in via UI. Those would otherwise be double-counted (once as Unlogged, once as Actor). The "Non-actor $" line is adjusted so the totals reconcile.

The Actors column

Actors comes from usage-actors.json (written by the Analyze Usage button). The file records, per (object, recordTypeId), the user IDs that created or modified at least one record in the analysis window:

{
  "actors": [
    {
      "objectType": "Opportunity",
      "recordTypeId": "012XXX…",
      "modifierIds": ["005XXX…", "005YYY…"],
      "creatorIds":  ["005ZZZ…"]
    }, …
  ]
}

The panel takes the union of modifier and creator IDs across all (object, RT) entries, intersects them with the user list per profile, and counts.

Actors are usually a strict subset of Logins — a logged-in user doesn't necessarily do anything. If you see "Actors > Logins" for a profile, you've found a profile where API-only integration accounts produce DML without showing up in interactive login logs. That's a useful flag.

Reading the panel

Two patterns:

"Are we over-licensed?"

Sort the Licenses sub-tab by Available desc. The licences with the biggest gap between Provisioned and Used are your renegotiation targets.

Then on the Profiles tab, expand a high-cost profile and look at:

• Logins (30d) / Users — if a profile has 50 users and 5 of them logged in in the last month, that's 45 seats up for grabs.

• Actor $ / Assigned — if the actor cost is a small fraction of total assigned cost, the seats may exist mostly as a vanity setting.

"Who actually works in this org?"

Sort the Profiles tab by Actor $ descending within the Named bucket. The top 5-10 profiles are doing the real work. Everything below the long tail is, charitably, optional.

For Community Login orgs, sort by Logins (30d) descending — actors don't apply the same way since community users may interact via portal in ways that don't hit Salesforce DML directly. Logins is the better signal there.

Where the numbers come from

All of it is computed at render time from licensingAnalysis in the version JSON + the usage-actors.json file. Nothing's hard-coded.

Going deeper — the DML sub-tab

Once you've identified profiles that look suspicious in the Profile sub-tab, the DML sub-tab classifies their users into activity buckets based on Event Log Files. That's its own document — see DML analysis and ELF.