Work 365 – Permissions for Azure Active Directory

Applies To: Work 365 (Dynamics 365 / Power Platform)
Audience: System Administrators, Azure AD (Microsoft Entra ID) Administrators, Implementation Teams

Overview

Work 365 relies on Microsoft Entra ID (formerly Azure Active Directory) for sign-in and identity. To operate securely with Dynamics 365/Dataverse, Work 365 needs one tenant-wide admin consent that grants two delegated permissions.

Required permissions

• Permission: User.Read Purpose: Allows Work 365 to read the signed-in user’s basic profile (name, email, tenant ID) for sign-in and personalization.
• Permission: Access Common Data Service (Dataverse) as the logged-in user (a.k.a. Dynamics CRM “user_impersonation”) Purpose: Lets Work 365 access Dataverse using the user’s context for secure, audit-friendly data operations.

These are granted once per tenant by a Global Administrator so users aren’t prompted individually.

Why Global Administrator consent is required

• Centralized access control: Users can sign in without repetitive consent prompts.

• Creates a Service Principal: Establishes a trusted app identity in Entra ID for Work 365.

• Enables automation: The service principal can be added as an Application User in Dataverse to run background jobs without a human license.

Steps to grant permissions

1. Sign in to Azure Portal
   Go to https://portal.azure.com with a Global Administrator account.

2. Open Enterprise applications
   Entra ID → Enterprise applications → search/open the app named Work 365 (or your Work 365 app display name).

3. Review API permissions
   Enterprise application → Permissions (or Security → Permissions) and verify you see:

• User.Read

• Access Common Data Service (Dataverse) as the logged-in user (Dynamics CRM user_impersonation)

1. Grant tenant-wide admin consent
   If consent isn’t granted, click Grant admin consent for and confirm. Status should show Granted.

2. Verify & test
   Users should no longer see consent prompts. Admins can proceed to configure/assign the Application User in Dataverse for Work 365 background operations.

Best practices

• Use an Application User for all Work 365 automations (stable, license-free, not tied to human passwords).

• Least privilege: Only the two delegated permissions above are required for core operation—avoid unnecessary Graph scopes.

• Document the event: Record who granted consent, when, and for which app (App ID).

• Periodic review: Re-confirm permissions and app ownership during quarterly security reviews or tenant changes.

Troubleshooting

Users still see consent prompts

• You granted consent on the App registration but not on the Enterprise application object. Open Enterprise applications → → Permissions and grant consent there.

“Grant admin consent” button missing

• Ensure you’re signed in as a Global Administrator in the correct tenant.

401/403 errors when loading Work 365 pages

• Re-run consent, then in Work 365 go to Admin Hub → Service Configuration → Get/Change Consent.

• Verify the Work 365 Application User exists and has Work 365 Service and Work 365 Portal Service roles.

Multiple environments (Prod/Sandbox)

• Consent is tenant-wide, but each environment still needs its Application User set up and roles assigned.

Government clouds

• Names may appear as Dynamics CRM (user_impersonation) in API permissions; the requirement is the same.

Related tasks

• Set up the Application User for Work 365: Create the App User in Power Platform Admin Center, assign Work 365 Service and Work 365 Portal Service roles, then select it in Work 365 → Admin Hub → Change Service User and Clear Cache.

Summary

Work 365 needs User.Read and Dataverse access as the logged-in user via a single tenant-wide admin consent. This creates a trusted service principal, enables secure authentication, and supports stable background processing through an Application User—delivering a seamless experience for end users and administrators.