Permissions

For the Zation FinOps Platform to read your usage and cost data and compute recommendations, it needs defined permissions in your Microsoft environment. The Platform adheres strictly to the principle of least privilege — every scope is read-only, and Zation never requests access to message content, files, chat data, or sign-in event details.

Five consent surfaces may be involved, in this order:

1. Enterprise app — Client Auth — a multi-tenant Microsoft Entra ID app for portal sign-in. Required for every customer, including customers who only use Zation for Cloud Solution Provider (CSP) billing.
2. GDAP — Granular Delegated Admin Privileges for CSP customers.
3. Microsoft 365 — Graph application permissions — required only if you enable the Microsoft 365 or Intune modules.
4. Audit-based usage evidence — Dynamics 365, Copilot, and Power BI — listed as required in the Platform's permission check; grant it to get audit-confirmed usage signals for these three areas. Without it the Platform keeps working and falls back to proxy signals.
5. Azure — ARM service principal roles — required only if you enable the Azure module.

1. Enterprise app — Client Auth

A single multi-tenant application registration owned by Zation. Every customer consents to this app once so their users can sign in to the Platform with their existing Microsoft work account. This consent is required even for customers who only use Zation Platform for CSP billing and have not enabled any data-collection module for Microsoft 365 or Azure.

Permission	Type	Purpose
openid	Delegated	Issues the sign-in token.
profile	Delegated	Reads display name and object ID from the token.
User.Read	Delegated	Lets the portal fetch the signed-in user's basic profile on /me.

Why a Global Administrator?

Only a Global Administrator can grant tenant-wide consent. Once granted, any regular user from your tenant can sign in to the Platform — no re-consent needed.

2. GDAP — for CSP customers

When Zation acts as your CSP partner for Microsoft 365 licenses, license-administration tasks run through Granular Delegated Admin Privileges (GDAP). This replaces the older Delegated Admin Privileges (DAP) model, deprecated by Microsoft since 2024.

DAP is deprecated

If your tenant still has a DAP connection, Zation will migrate it to GDAP during onboarding. New customer tenants no longer accept DAP.

GDAP properties:

• Granular: only the roles Zation needs — never Global Administrator.
• Auditable: every admin action is logged in the customer audit log.

The specific Entra ID roles Zation requests through GDAP are kept to the minimum required for CSP license administration and are reviewed with you during onboarding.

3. Microsoft 365 — Graph application permissions

Requested when you enable the Microsoft 365 or Intune modules. Granted via admin consent on a separate enterprise application. Every scope is a .Read scope — Zation never holds write access on Microsoft Graph.

Permission	Type	Purpose
Directory.Read.All	Application	Users and basic profile (department, job title, usage location), admin roles, groups, shared mailboxes, and subscribed SKUs with consumed-vs-purchased counts.
User.Read.All	Application	Per-user profile detail and license assignments.
Reports.Read.All	Application	Aggregated 30-day usage counters per user (Outlook, Teams, SharePoint, OneDrive, Copilot) for the Adoption module.
AuditLog.Read.All	Application	Per-user last sign-in for dormant-account detection, and MFA registration state. No sign-in event details stored.
DeviceManagementManagedDevices.Read.All	Application	Intune-managed device inventory.
DeviceManagementApps.Read.All	Application	Intune app-protection (MAM) registrations, for mobile-only detection on BYOD tenants that manage apps without enrolling devices. Optional — without it the Intune sync stays device-management-only.
TeamsUserConfiguration.Read.All	Application	Per-user Teams calling and conferencing settings.
CallRecords.Read.All	Application	Teams call-record metadata (duration, participant count). No call audio or transcripts.

MFA registration state comes from the Microsoft Graph userRegistrationDetails report, which requires AuditLog.Read.All only. For the exact scope each call needs, see the Microsoft Graph permissions reference.

4. Audit-based usage evidence — Dynamics 365, Copilot, and Power BI

Looking for the step-by-step version?

This section is the reference for what each grant contains. For the order to do things in, how to check whether each level arrived, and the per-table auditing layer, see How Zation gets Dynamics 365 data.

One permission unlocks audit-confirmed usage signals for three areas at once: Dynamics 365 seat rightsizing (inactive users, module mismatches, attach-eligible seats), and richer Copilot and Power BI recommendations based on real interaction counts rather than last-activity timestamps alone. It draws on two consent surfaces; the second is optional, Dynamics-365-specific, and needed only for licence-tier rightsizing.

4a. Office 365 Management Activity API

An application permission on the Office 365 Management APIs resource, granted via admin consent. It returns audit-event metadata for all three areas — which user touched which app or workload, and when — never the business records, files, or Copilot prompt/response text behind those events.

Same app as section 3 — no new registration

This permission is added to the same enterprise application that holds the Microsoft 365 Graph permissions (section 3), not to the sign-in app and not to a new registration. You add ActivityFeed.Read as one more application permission on that existing data-collection app and grant admin consent once.

Permission	Type	Purpose
ActivityFeed.Read	Application	Audit-event metadata (user, app or workload, timestamp) driving three signal families: Dynamics 365 inactive-user/module-mismatch/attach-candidate detection, Copilot interaction-frequency evidence, and Power BI usage evidence. No record content, no field values, no Copilot prompt/response text.

Granting it once improves all three areas together — you can't pick just one. Without it:

• Dynamics 365 falls back to M365-proxy signals (last sign-in / general activity) instead of audit-confirmed Dynamics usage.
• Copilot and Power BI recommendations fall back to the Microsoft Graph usage reports' last-activity timestamps, the same signal used before this permission existed.

Auditing must be on

These audit events only reach the Platform when the tenant's unified audit log is enabled. Dynamics 365 additionally needs auditing turned on for each environment — without it, Dynamics activity events specifically are absent and the Dynamics 365 module reports every user there as inactive. Copilot and Power BI evidence only need the tenant-wide unified audit log.

4b. Microsoft Dataverse — Zation License Reader role (optional, Dynamics 365 only)

Tier rightsizing — recommending Professional, Enterprise, or Premium for each seat — needs to know which capabilities an environment actually deploys. Zation reads that from Dataverse configuration metadata through a purpose-built, read-only custom security role assigned to the Zation application user in each environment.

Property	Value
Role name	Zation License Reader
Access level	Read, Organization scope
Write / create / delete	None on any table

Three read privileges. That is the whole grant:

Privilege	Reads
prvReadUser	who the users of the environment are
prvReadRole	which security roles exist, and who holds them
prvReadSolution	which solutions are installed, and what they contain

Nothing else. These three cover every table Zation touches, because in Dataverse the child and link tables — roleprivileges, privilege, systemuserroles, solutioncomponent — carry no privilege of their own; reading them comes with the read on their parent. Granting them separately would add rights without adding access.

None of this holds business data. No customer-facing table — accounts, contacts, leads, opportunities, cases, or any custom entity — is readable through this role.

If you are looking at an older role

Roles built before September 2026 often carry more than these three, because adding a table in the role editor also sets related customization privileges. Extra read privileges on configuration metadata are harmless, but they are not something Zation asks for — and if you would rather trim an existing role to the three above, nothing on our side stops working.

Optional and per-environment

Assign the role once per Dynamics 365 environment you want tier recommendations for. Skip it and the module still detects inactive users, module mismatches, and attach candidates — only the Professional / Enterprise / Premium tier recommendation is withheld.

The Power Platform Reader role saves the host list, not this step

Granting the tenant-wide Power Platform Reader role once has the Platform discover every Dataverse environment automatically, so nobody has to enter environment hosts by hand. It does not replace the application user below: listing environments and reading inside one are separate grants on separate planes, and without the application user every read returns 401 or 403.

This role is a Microsoft preview feature with no admin center UI — it can only be assigned through a PowerShell script against a preview API, so ask your Zation contact to walk through it with you. If you would rather not, enter the environment hosts by hand under Organisation settings → your tenant → Dataverse environment hosts; everything below works either way.

How the role connects — the application user

The role is assigned to a Dataverse application user — a service principal that lives inside the environment and is matched to Zation's enterprise application by its Application (client) ID. There is no separate credential and no secret to manage: the environment recognises Zation's app token by that client ID and applies whatever role the application user holds.

To set it up, in the Power Platform admin center:

1. Open the environment → Settings → Users + permissions → Application users.
2. + New app user, then add the app by the same Application (client) ID used for the Microsoft 365 connection (section 3).
3. Assign it the Zation License Reader security role.

You grant it once per environment; nothing is stored on the Zation side beyond the enterprise application it already uses. This is the same application-user model Zation uses for its own Dynamics 365 connection.

5. Azure — ARM service principal roles

Requested when you enable the Azure module. A Zation service principal is granted the following built-in Azure roles at the subscription or management-group scope you choose. No data inside any resource is accessed.

Role	Purpose
Reader	Inventory of all resources, SKUs, and tags. Its */read action also covers metrics, Log Analytics, backup vaults, and emissions data.
Cost Management Reader	Usage and cost data.
Reservations Reader	Reserved Instance (RI) inventory and utilization.
Savings plan reader	Savings-plan inventory and utilization.

Reader alone is not sufficient for cost data on Enterprise Agreement (EA) billing scopes — Microsoft requires Cost Management Reader there. See Assign access to Cost Management data.

Reservation and Savings Plan roles are tenant-scoped

Reservations Reader and Savings plan reader are not inherited from a management-group or subscription Reader assignment. Assign each one once at tenant scope: Reservations Reader at /providers/Microsoft.Capacity and Savings plan reader at /providers/Microsoft.BillingBenefits. The PowerShell script linked from platform.zation.io → Setup does both for you.

Network — where Zation connects from

Permissions define what the Platform may read. The network controls below define from where — useful if your tenant restricts access by IP address as well as by scope.

• Outbound: every connection the Platform makes to your Microsoft environment — Microsoft Entra sign-in, Microsoft Graph, and Azure Resource Manager — leaves from one fixed, reserved IP range shared by all customers:

  Range (CIDR)	First address	Last address
  20.250.10.216/30	20.250.10.216	20.250.10.219

  Allowlist the whole /30 — a single request can leave from any of the four addresses. You can put a Microsoft Entra Conditional Access policy on the Zation enterprise application that accepts sign-ins only from that range.

• Inbound: the Platform is served through a global edge layer, and the application origins accept traffic from that edge only. On request, Zation can additionally restrict access to your Platform tenant to IP ranges you define, so a valid sign-in from any other network is rejected.

Conditional Access on the Zation app needs Workload ID Premium

The Platform authenticates as a service principal, not as one of your users. Applying Conditional Access to a workload identity requires Microsoft Entra Workload ID Premium in your tenant. A Conditional Access policy on user sign-ins does not cover the Platform's data collection.

Signed-in customers find the step-by-step named-location setup and the inbound allowlist guide under Static egress IPs and Inbound IP allowlist.

What Zation does not require

• No write access to any resource — Zation cannot create, change, or delete anything in your tenant.
• No mail, calendar, or contact data — Mail.Read, Calendars.Read, and Contacts.Read are never requested.
• No file or chat content — Files.Read, Chat.Read, and ChannelMessage.Read.All are never requested.
• No Teams call audio or transcripts — only call-record metadata.
• No Dynamics 365 business records — accounts, contacts, leads, opportunities, and cases are never read; the Dynamics 365 module sees activity-event metadata and configuration metadata only.
• No Copilot prompt or response text — the audit feed carries only opaque interaction metadata (user, app, timestamp), never prompt or response content.
• No service principals with client secrets are created in your tenant.
• No raw sign-in event logs — only the lastSignInDateTime aggregate per user.

For data residency, encryption, and the full field-by-field data catalogue, see Security.