What We Actually Collect for a D365 License Analysis, and Why Each Piece Matters

Clients ask a reasonable question early in most engagements: why do you need all of this? A license number that holds up under scrutiny isn't produced from one report. It comes from joining several datasets that each answer a narrow question on their own, and only become a defensible number once they're read together. Here's what we actually pull, in the order we pull it, and why each piece earns its place.

Why we start with the population, not the roles

Active Users, Invalid Users, and Application Users all answer one underlying question: who is actually in scope? Skip this step and every later number inherits the mistake: stale accounts inflate the count, integration accounts get billed like people, and role analysis runs against a population that was never accurate to begin with. This is the cheapest, fastest cleanup in the entire process, and it's the one most reviews skip.

Why activity gets checked twice, not once

User Activity Aging is fast and UI-based, which also makes it incomplete. It misses thin clients and integration-driven work by design. Telemetry fills that gap operationally, but has its own blind spots around action and output menu items. Neither source is trustworthy alone. Together, treating a user as active if either source shows activity, they produce a population that's genuinely defensible rather than merely fast to produce.

Why we go past the role name into the entry point

Security User Role Association, User License by Role, and Security Analysis exist because a role's name tells you almost nothing about what it actually costs. The License Role and Privilege Requirements views are what turn "this role requires Finance" into "this specific entry point, under this specific privilege, is the one requiring Finance." See our roll-up mechanics series for the full logic. Without that specificity, every recommendation is a guess dressed up as an analysis.

Why telemetry only counts once it's paired with something else

Telemetry answers "what did people actually touch," which is powerful, but only when it's checked against Security Analysis (what they could touch) and transactional evidence (what they created or modified even when the UI stayed quiet). Used alone, telemetry can lead to deactivating a genuinely active integration user just because their work never shows up as UI clicks. Used together with the other two, it becomes the strongest evidence in the entire review for what's actually safe to remove.

Why device and service roles get their own pass

Not every access path is meant to carry a named-user license in the first place. Device classifier roles and the large family of integration and background-operation roles exist precisely because Microsoft doesn't want shared devices or service accounts billed like individual business users. See our quick reference for the working list. Confirming these are classified correctly protects against two mistakes in opposite directions: over-licensing a shared warehouse scanner, and under-governing an integration account that's quietly been given more access than a no-license role should carry.

Where the official guidance lives

How we actually pull each one

The table above is the "why." Here's the "how," the actual navigation path for every dataset, generalized from a real collection run. Three collection methods cover almost everything: a direct View/UI form, a Data Management Framework (DMF) export project, or the generic Table Browser pointed at a specific table name.

Telemetry lives outside F&SC entirely

Every dataset above sits inside the F&O database. Telemetry doesn't, it lives in Application Insights, a separate Azure resource with its own access grant. We query it in KQL, in Azure Monitor Logs, switched to KQL mode. The short version:

pageViews
| project timestamp, name, user_Id, duration
| sort by timestamp desc

And the version scoped to a single environment, useful once a tenant has more than one:

pageViews
| extend environmentId = tostring(customDimensions['environmentId'])
| project timestamp, name, user_Id, duration, environmentId
| sort by timestamp desc

For the full Application Insights setup, what it costs against Microsoft's free tier, and the complete KQL used to turn this into a license and activity report, see our telemetry configuration walkthrough.

The questions that don't come from a table at all

Once the exports are in hand, we ask the client a short list of questions no dataset answers on its own:

• Business context. What lines of business, and which Finance & Operations modules are actually in use.
• User activity patterns. Shift work, warehouse and manufacturing floor execution, which third-party applications talk to D365 F&SC, and what integrations exist.
• Device roles. Are any security roles used exclusively on shared devices, warehouse mobile scanners, POS terminals, execution-floor kiosks? Those map to device-based classifier roles rather than named-user licenses.
• Integration roles. Which roles are the entry point for another application, Sales, Project Operations, Field Service, Expense Management, an ISV, or another Dataverse app?
• Excluded domains. Which domains belong to partners, not employees.

That last set of questions is really about classifying roles correctly before they ever reach the license calculation, batch job managers, business events roles, data management users, system administrators, and the roughly 50 other integration and background-operation roles that exist precisely because Microsoft doesn't want a service account billed like a person. See our quick reference for the full list.