How Zation gets Dynamics 365 data
Dynamics 365 is the one module where Zation's answer depends heavily on how much access you grant. Everything else in the Platform reads Microsoft 365 or Azure through one connection; Dynamics 365 evidence arrives through three separate channels, and each one unlocks a different class of recommendation.
This page is the task-oriented walkthrough. Permissions is the reference for what each grant contains and why; this page is the order to do things in, how to tell whether it worked, and what you lose by stopping early.
The three levels
| Level | What it needs from you | What you get | What Zation withholds without it |
|---|---|---|---|
| 1 · Licence | Nothing — rides on the Microsoft Graph permissions from onboarding Step 3 | Who holds which Dynamics 365 licence, what it costs, unassigned seats, cost per department/country/cost centre | — |
| 2 · Privilege | Environment discovery + an application user with a read-only role in each Dataverse environment | Which capabilities an environment actually deploys, and therefore whether a seat's tier (Professional / Enterprise / Premium) fits | Tier recommendations |
| 3 · Usage | ActivityFeed.Read + auditing on at three layers | Whether a seat is actually used, and at write level whether a Full seat could be a Team Members seat | Inactivity evidence, and every write-level rightsizing recommendation |
The levels are independent — you can do 1 and 3 without 2, or 1 and 2 without 3. They are also cumulative in value: level 1 tells you what you pay, level 3 tells you what you waste.
If you only ever complete onboarding Step 3, the Dynamics 365 cost pages are already populated. Levels 2 and 3 are about recommendations, not about seeing your licence estate.
Level 2 — Privilege: let Zation see what an environment deploys
Tier rightsizing asks a question that licence data cannot answer: does this Enterprise seat sit in an environment that even deploys Enterprise capabilities? Zation reads that from Dataverse configuration metadata — security roles, privileges, role assignments, solution components. Three read privileges on configuration metadata, no business data. The exact grant is in Permissions § 4b.
This takes two steps, and both are needed:
| What it does | Where | |
|---|---|---|
| Environment host (required) | Tells Zation which environments exist | Entered by hand in the Platform, per environment |
| Application user (required) | Lets Zation read the configuration metadata of an environment | Per environment |
Enter each environment host under Organisation settings → your tenant → Dataverse environment hosts — the environment URL without https://, for example contoso.crm4.dynamics.com. Without the application user, every read into a known environment returns 401 or 403 and the tier sync stays dormant.
Zation can't discover your environments automatically. Microsoft excludes the environment list from Power Platform role-based access, so a read-only app identity gets 403 even with the Power Platform Reader role assigned. The only registration that opens it grants full administrator rights, and Zation doesn't ask for that. See Known limitations.
Step 1 — an application user per environment (required)
Do this per environment you want tier recommendations for. Repeat for each one; environments you skip simply have no tier recommendation.
- Open the Power Platform admin center → Environments → select the environment.
- Settings → Users + permissions → Application users.
- + New app user.
- + Add an app → search for your Zation Platform Connector App Registration (the same one from onboarding Step 2 — not a new registration) → Add.
- Pick a Business unit — the root business unit is correct; the role is Organization-scoped read anyway.
- Under Security roles, select
Zation License Reader, then Create.
An application user without a security role is not a working grant — it authenticates and then gets refused. Creating the app user and assigning the role are two separate things in this dialog, and it is easy to complete the first and leave the second. The troubleshooting table below tells the two apart.
If the Zation License Reader role does not exist yet
The role is a custom, read-only role that has to exist in the environment before you can assign it. If it is not in the list, ask your Zation contact for the role definition (a solution file) or create it manually: Settings → Security → Security roles → New, access level Read / Organization on the seven privileges named in Permissions § 4b, and no Create, Write, Delete, Append, Assign or Share anywhere — apart from the four SharePoint privileges Dataverse sets on every new role and doesn't let you remove.
How to tell whether level 2 worked
Zation checks three things in order, and stops at the first one that is not satisfied — so the first failure is the one to fix:
- Environment found. Zation knows a host at all — entered by hand under Organisation settings → your tenant → Dataverse environment hosts.
- Access granted. A live call into the environment succeeds. Fails when the application user or its role is missing.
- Signal written. A sync has actually stored capability data for that environment. This one is about timing more than access — see the note below.
Tier recommendations appear after the next nightly sync, not immediately.
The Dynamics 365 sync runs nightly. A grant made during the day shows up the following morning. If it has been more than 24 hours, it is worth reporting rather than waiting.
Troubleshooting level 2
| Symptom Zation reports | Cause | Fix |
|---|---|---|
| Environment not found / no environments listed | Zation doesn't know a host — nobody has entered one | Enter the host under Organisation settings → your tenant → Dataverse environment hosts |
| Environments are listed, but no tier signal is ever written | The host is known, the application user is not — discovery and reading are separate grants | Add the application user per environment (Step 1) |
| Access refused — application user missing | The App Registration was never added as an application user in that environment | Step 1, items 1–4 |
| Access refused — role missing | The application user exists but carries no security role, or a role without the first three read privileges | Step 1, item 6 |
| Authentication refused | Zation's own client secret has expired or been rotated. Not something you can fix | Report it — it is on our side |
| Access fine, but still no tier recommendation after 24 h | Sync has not stored capability data yet | Report it |
The middle two look identical from the outside — "it does not work" — and have different fixes, which is why Zation distinguishes them explicitly rather than reporting one generic failure.
Level 3 — Usage: the layer that is most often half-configured
Level 3 is what turns "this person holds a Full seat" into "this person holds a Full seat and has not written anything in 90 days that requires one". It needs two things: the permission, and auditing.
The permission
ActivityFeed.Read on the Office 365 Management APIs, on the same App Registration, with admin consent. Full walkthrough in onboarding Step 4.
This permission is shared with Copilot and Power BI evidence — granting it improves all three at once, and you cannot grant it for only one.
Auditing — three layers, not two
This is the part that most often goes wrong, and it goes wrong quietly. Auditing in a Dynamics 365 tenant is not one switch:
| Layer | Where | Without it |
|---|---|---|
| 1. Tenant unified audit log | Microsoft Purview → Audit → Start recording user and admin activity | No audit evidence at all, for Dynamics 365, Copilot and Power BI |
| 2. Environment auditing | Power Platform admin center → environment → Settings → Audit and logs → Audit settings → Start auditing | That environment emits no events; every user in it looks inactive |
| 3. Table auditing | For each table you care about: Settings → Customizations → Customize the system → Tables → <table> → General → Auditing (or the same checkbox in the modern maker portal) | Events arrive, but without an identifiable target — see below |
Layers 1 and 2 are covered in onboarding. Layer 3 is the one that is easy to miss, because after enabling layers 1 and 2 the admin center honestly reports that auditing is on.
On one tenant we measured, 7'343 of 7'349 write events carried no identifiable target table. Auditing was on at tenant and environment level; table-level auditing was not.
Zation does not guess in that situation. A write whose target we never saw cannot support the claim "this person writes nothing that needs a Full seat" — that is the absence of evidence, not evidence of absence. So the write-level recommendation is withheld, and you see a data-readiness note instead of a CHF figure.
That is deliberate: a downgrade recommendation built on unreadable evidence would move a user onto a licence their actual work does not permit.
Which tables to enable depends on what you use. At minimum, the ones your users work in daily:
- Sales —
account,contact,lead,opportunity,quote,salesorder,invoice - Customer Service —
incident(Case),entitlement,knowledgearticle - Field Service —
msdyn_workorder,bookableresourcebooking,msdyn_agreement - Activities —
task,appointment,email,phonecall,annotation(Note) - Plus any custom tables your users write to
Zation classifies each write against Microsoft's Team Members use rights. A write to a custom table is one it cannot classify — and if most of a person's writes are unclassifiable, the recommendation for that person is withheld rather than estimated. Enabling auditing on your custom tables makes those users assessable.
Field-level auditing is not required
Dataverse also offers auditing per field. Zation does not need it and does not read field values — only that a write happened, to which table, by whom, and when. Leave field-level auditing as it is.
How long until level 3 pays off
Auditing is not retroactive: it produces evidence from the moment you switch it on. Write-level rightsizing needs a meaningful observation window before it will state anything, so expect the first write-level recommendations weeks after enabling auditing, not the next day. Inactivity signals appear sooner.
What Zation does when a level is missing
The Platform degrades rather than guesses, and it says which:
- No level 3 — Dynamics 365 falls back to Microsoft 365 proxy signals (last sign-in, general activity) instead of audit-confirmed Dynamics usage. You still get inactivity candidates; they are weaker evidence and are labelled as such.
- No level 2 — inactivity, module mismatch and attach candidates still work. Only the Professional / Enterprise / Premium tier recommendation is withheld.
- Partial level 3 (auditing on, table auditing off) — the module reports a data-readiness item instead of a saving. This is the case worth fixing first: it looks configured, and it produces nothing.
A withheld recommendation is always shown as withheld, with the reason. Zation never fills the gap with an estimate.
Checklist
Level 1 — nothing to do beyond onboarding Step 3.
Level 2:
- Environment hosts entered by hand under Organisation settings → your tenant → Dataverse environment hosts
- Application user added per environment with the
Zation License Readerrole
Level 3:
-
ActivityFeed.Readgranted on Office 365 Management APIs, with admin consent - Tenant unified audit log on (Purview)
- Environment auditing on, per environment
- Table auditing on, per table — including custom tables