In short
Admin consent in Microsoft Entra ID is a tenant-wide grant of data access, not a formality. We break down what the requested scopes actually expose, which Entra role should approve, and how to document and rehearse the revocation path before you click Grant.
Key takeaways
- Application permissions let an app call Microsoft Graph with its own identity, with no signed-in user, and reach any data the permission covers, such as every file in the organization.
- Only Privileged Role Administrator and Global Administrator can consent to Microsoft Graph application permissions; Cloud Application Administrator covers everything else.
- Requiring user assignment blocks unassigned users from signing in, but it does not narrow what an app-only identity can read.
- Tenant-wide grants can be reviewed in the Admin consent tab of Enterprise apps and revoked per permission, but revocation does not stop users from re-consenting.
- Demand an endpoint-to-purpose matrix from the vendor: each permission mapped to a feature, with the impact stated for permissions you decline.
What access is the administrator actually granting?
When the consent prompt appears, you are not approving a login. You are granting an application a set of API permissions against your Microsoft 365 tenant, on behalf of the whole organization. Microsoft is explicit about the stakes: granting admin consent on behalf of an organization is a sensitive operation that can give the application's publisher access to significant portions of your organization's data, or the ability to perform highly privileged operations such as role management, full access to all mailboxes or all sites, and full user impersonation.[1] Treat the prompt as a data-access contract and read it line by line before you click Grant.
An application requests the API permissions it needs, and depending on what it asks for, the request may be routed to an administrator rather than to an end user.[2] Before you reach any individual permission, the consent screen tells you three things you should check: the application's identity, the publisher behind it, and the exact list of scopes requested.
- The application identity: the display name and the client ID, also called the application ID, which you can use to pull up the same application in your own Microsoft Entra admin center.
- The publisher: the organization accountable for the app, and whether Microsoft has verified that organization as authentic.
- The requested permissions: each scope, named in the {resource}.{operation}.{constraint} pattern that Microsoft Graph uses.
That naming pattern is your translation tool. The resource tells you which Graph data the permission touches, the operation tells you whether the app can only read or also write, and the constraint tells you how far the access reaches.[3]
| Part of the permission name | What it tells you | Examples |
|---|---|---|
| Resource | Which Microsoft Graph resource the permission grants access to | User, Group, Files |
| Operation | What the app can do with that resource | Read, ReadWrite |
| Constraint | How far the access extends within the directory | All, OwnedBy, Selected |
Translate every scope before you approve, and judge a comms analytics request on what each permission exposes, not on vendor assurances. A read-only grant is not automatically narrow: an application granted the Files.Read.All application permission can read any file in the organization.[3] The word Read in the name does not reduce the reach described by All.
How do delegated and application grants differ?
Microsoft Graph supports two access scenarios: delegated access, where the app calls Graph on behalf of a signed-in user, and app-only access, where the app calls Graph with its own identity, without a signed-in user.[3] The difference determines the blast radius of your approval, so identify which one you are looking at before anything else.
| Delegated permissions (scopes) | Application permissions (app roles) | |
|---|---|---|
| Access context | On behalf of a signed-in user | Without a signed-in user |
| Reach | Nothing the signed-in user could not access | Any data the permission is associated with |
| Typical app type | Web, mobile or single-page app | Web service or daemon |
| Who can consent | User or admin, depending on tenant policy | Admin only |
In a delegated scenario, the privileges the app has are determined by the granted permissions and the user's own permissions combined: acting for Tom, an app with Files.Read.All can only read files Tom can already access.[3] In an app-only scenario there is no user ceiling. That is why Microsoft recommends the delegated permission model from a least-privilege perspective whenever it meets the application's requirements, and why an app-only request deserves the stricter half of your review.
Expect a background analytics operation to ask for app-only access, because that is what its job requires: reading SharePoint and Viva Engage activity across the tenant on a schedule, whether or not anyone is signed in. The native reporting gaps that push your comms team to request an analytics layer in the first place are real, from fragmented per-tool dashboards to the 30-day reporting window without premium licences described in Viva Connections analytics. So the question is not whether application permissions appear in the request, but whether each one is the least-privileged scope that delivers a feature you actually commissioned.
Which identity is allowed to approve the request?
Consent authority depends on the permissions requested and the administrator role, not on job title or seniority.[2] Microsoft's role model splits the approval right into three tiers, and knowing them lets you route the request instead of escalating it to whoever happens to hold the biggest role.
- Privileged Role Administrator: can grant consent for apps requesting any permission, for any API.
- Cloud Application Administrator, AI Administrator or Application Administrator: can grant consent for apps requesting any permission for any API, except Microsoft Graph app roles, meaning application permissions.
- Custom directory role: a role that includes the permission to grant permissions to applications can be scoped to exactly the permissions this class of approval needs.
Application permissions are the exception that matters here: only Privileged Role Administrator and Global Administrator can consent to them.[3] Since a background analytics deployment will include app roles, the final decision will land with one of those two identities. Between them, Privileged Role Administrator is the narrower grant; Global Administrator should not be your default approver for every consent request that crosses the desk.
The custom-role option is the one to build on for repeatable governance. Scope a directory role to granting permissions for this category of request, hand it to the identity that owns vendor approvals, and keep tenant-wide consent decisions off your most privileged accounts. Route the approval deliberately, and the role assignment itself becomes part of the audit record.
What evidence should the vendor provide first?
Set the documentation bar before the first demo, not after the contract. Require an endpoint-to-purpose matrix: every requested Graph permission mapped to the feature it enables and the data it reads, written so that both your IT team and the comms stakeholders can follow it. A vendor that cannot explain why a scope is needed is asking you to accept a risk it has not analysed itself.
Microsoft's guidance to developers tells you what a well-prepared request looks like: permissions should be statically defined in the app registration and form a superset of anything the app requests dynamically, so a tenant admin can review the full list and consent once in the portal, rather than meeting new scopes after deployment.[4] Ask the vendor to confirm that its permission list is static and complete, and to version it, so a later update that adds scopes triggers a fresh review instead of a surprise.
Then ask for the app's client ID and check publisher verification. When a publisher is verified, Microsoft has confirmed the authenticity of the publishing organization through a verified partner account, and a blue verified badge appears in the consent prompt.[5] Know the limit of that badge: Microsoft states plainly that it does not indicate quality criteria, certifications or adherence to security best practices. Pair it with the evidence that does speak to workforce data handling, the SOC 2 Type 2 status, GDPR posture and data residency that security and compliance guidance for IC analytics tells you to gate a vendor on.
Finally, verify in your own tenant rather than trusting a sales deck: open Enterprise apps, select the application, and read the permission list under Permissions. A vendor's own breakdown of what its analytics layer reads across a Microsoft 365 tenant, and what it deliberately does not, is the standard of specificity to expect from any vendor asking for tenant-wide consent.
How do assignment restrictions affect user access?
Two controls get confused in approval meetings: who can sign in to the application, and what an app-only identity can read. They are different levers. By default, granting tenant-wide admin consent allows all users to access the application unless you restrict it; to limit sign-in, you configure the app to require user assignment and then assign users or groups.[1]
| Control | What it governs | What it does not do |
|---|---|---|
| User assignment | Which users can sign in to the app and obtain tokens | Does not narrow application permissions |
| Application permissions (app roles) | What the app's own identity can read across the tenant | Does not depend on who is assigned to the app |
| Tenant-wide consent | Grants the requested permissions on behalf of the whole organization | Is not undone by unassigning users |
The distinction has a hard edge for an analytics deployment: requiring assignment blocks unassigned users from signing in, but the application's service identity still reads whatever its app roles cover, regardless of the assignment list. User assignment does not scope every app-only permission. Assignment controls who sees the dashboard; only the scope review from the earlier sections controls what data the service reads.
Set it up accordingly. Assign the comms team and any executive report consumers to the application so the dashboard audience is deliberate, and treat the permission list you approved as the single lever on data exposure. If segmented views raise questions about who may see group-level engagement data, that is a dashboard-permissions decision, and the trade-offs between anonymised versus identifiable data are worth reading before go-live, not after the first works council question.
How can grants be reviewed or revoked later?
Treat the grant as a lifecycle object with an owner, a review trigger and a tested exit path, not a one-time checkbox at deployment. The audit surface is already in your admin center, and you should know where it is before the day you need it.
- Enterprise apps, then Permissions, then the Admin consent tab: shows the permissions granted tenant-wide for the application.
- The User consent tab: shows permissions granted to a specific user or group.
- Revocation: a Cloud Application Administrator can revoke a tenant-wide permission from the same pane, using the Revoke permission control.
Two mechanics matter before you ever press that button. First, permissions in the User consent tab cannot be revoked in the portal at all; removing them requires Microsoft Graph API calls or PowerShell cmdlets.[6] Second, revoking a granted permission does not stop users from re-consenting to the application's requested permissions; to close that door, you must tighten the tenant's user consent settings in the same move.[6]
Document three things at approval time, while the details are fresh. Record the grant owner: who approved which permission list, against which client ID, on what date. Define the review trigger: a permission change on the application, a vendor security incident, or contract end. And rehearse the withdrawal once in a test tenant: revoke the app roles, confirm the service loses access, and note what re-onboarding would take if you grant again. An exit path you have executed is a control; one you have assumed is a hope.
What should Communication Insights bring to approval?
Apply the same checklist to the request you are most likely to face: your comms team asking for cross-channel analytics. Ask Tryane for the current permission request for Communication Insights, the all-in-one cross-channel analytics platform that connects email newsletters, the SharePoint intranet, Viva Connections and Viva Engage into one central dashboard. Review it with the same endpoint-to-purpose matrix you would demand of any vendor: each permission mapped to the feature it powers and the data it reads, with nothing left justified by trust.
- Scope review: every requested permission justified, and the static permission list confirmed as complete.
- Role routing: consent granted by the least-privileged role that can approve the requested permission types.
- Assignment: dashboard users deliberately assigned, with data exposure governed by the approved scopes alone.
- Revocation: a named grant owner, a defined review trigger, and a withdrawal procedure tested in a test tenant.
Approve only after the scope review is complete, route the consent to the least-privileged role that can grant it, and file the revocation procedure alongside the approval record. Once consent is granted, the deployment side takes over: connecting each channel, structuring your audience model, and reading cross-channel KPIs in one place instead of four consoles. That is the work Communication Insights is built for, and it starts from the permission list you just reviewed.
If you want to walk through the consent request with the team that built it, review the Communication Insights consent requirements with Tryane: book a call and go through the permission list against your own tenant before you click Grant.
Frequently asked questions
What does admin consent actually give an application access to?
It grants the application the API permissions it requested on behalf of your whole organization. Microsoft describes this as a sensitive operation that can give the app's publisher access to significant portions of your data or highly privileged operations such as full access to all mailboxes or all sites, which is why the permission list must be reviewed before approval.
What is the difference between delegated and application permissions?
Delegated permissions let the app act on behalf of a signed-in user and only within what that user can already access. Application permissions (app roles) work without a signed-in user and let the app access any data the permission covers, for example every file in the organization. Microsoft recommends the delegated model from a least-privilege perspective whenever it meets the app's requirements.
Which Microsoft Entra role can grant tenant-wide admin consent?
It depends on the permissions requested. Privileged Role Administrator can consent for apps requesting any permission for any API. Cloud Application Administrator, AI Administrator and Application Administrator can consent for any permission except Microsoft Graph application permissions, which only Privileged Role Administrator and Global Administrator can grant. A custom directory role with the consent permission can also be scoped to the task.
If I limit the app to assigned users, does that reduce its data access?
No. Requiring user assignment and assigning specific users or groups controls who can sign in and obtain tokens. It does not scope an app-only identity: an application permission still covers whatever data it names, regardless of user assignment. Only the permission list itself controls what the service reads.
How do I review or revoke permissions after granting admin consent?
In the Microsoft Entra admin center, open Enterprise apps, select the application, then Permissions and the Admin consent tab to see tenant-wide grants and revoke individual permissions. Permissions granted by users must be removed via Microsoft Graph or PowerShell. Note that revoking a grant does not prevent users from re-consenting unless you also tighten user consent settings.
Is a read-only permission safe to approve automatically?
No. A read-only grant is not automatically narrow: an application permission such as Files.Read.All lets the app read any file in the organization without a signed-in user. Judge each scope by the data it exposes, not by the word Read, and require the vendor to justify every permission against a concrete feature.
What documentation should I require from a vendor before approving consent?
Ask for an endpoint-to-purpose matrix: every requested permission mapped to the feature it enables, the data it reads, and the impact if you decline it. Microsoft's vendor guidance recommends exactly this, plus a versioned permission list and publisher verification, so you can compare the request against what you see in your own tenant.
Sources
Further reading
• Viva Insights vs communication analytics: two different questions
• IC analytics data retention: what to set and why
If you want to see what cross-channel reporting looks like against your real data, Tryane runs a 15-minute walkthrough with no slides. Book a slot with Jérémy.