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 — optional; grant it to get audit-confirmed usage signals for these three areas instead of the proxy signals they fall back to without it.
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

One optional 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.

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

The role grants Read on seven system configuration tables only — security roles, privileges, role assignments, and solution components:

systemuser, role, roleprivileges, privilege, systemuserroles, solution, solutioncomponent.

None of these hold business data. No customer-facing tables — accounts, contacts, leads, opportunities, cases, or any custom entity — are readable through this role.

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.

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.

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.