Admin Approval Required Issue Across Multiple Apps

The behavior described matches Microsoft Entra consent and access controls blocking or re-prompting for consent across multiple apps. Several tenant and app-level settings can cause this, even after an admin has attempted consent.

Key areas to check and typical fixes:

1. Confirm admin consent is actually granted for each app
   • In Microsoft Entra admin center, for each affected app:
     • Go to Identity → Applications → Enterprise applications → [App] → Permissions.
     • Verify that the required delegated/application permissions are listed as Granted for [tenant].
   • If not, a Global/Privileged Role Administrator should explicitly select Grant admin consent for [Organization].
   • If using app registrations directly, the same can be done under App registrations → [App] → API permissions → Grant admin consent.
   • Missing admin consent is a primary cause of “Need admin approval” and AADSTS65001/AADSTS90094-type errors.
2. Check if user assignment is required for the enterprise apps
   • Even with tenant-wide admin consent, users can still be blocked if the app requires assignment:
     • Go to Microsoft Entra ID → Enterprise applications → [App] → Properties.
     • Check User assignment required? / Assignment required.
     • If set to Yes, either:
       • Set it to No to allow all users, or
       • Explicitly assign users or groups under Users and groups.
   • If this is enabled and users are not assigned, they will see errors like “User is not assigned to a role for the application” and effectively be blocked even though consent was granted.
3. Verify tenant-wide user consent settings and admin consent workflow
   • If user consent is disabled or restricted, non-admin users will be blocked from granting consent and see “Ask your admin” prompts.
   • In such cases, ensure:
     • Admin consent has been granted as above, and
     • If using the admin consent workflow, users are actually submitting requests and admins are approving them.
   • After approval, users should no longer see the consent dialog unless the app requests new permissions.
4. Check for incremental/dynamic consent and new permissions
   • Many apps (including third-party SaaS) use incremental/dynamic consent to request additional scopes later.
   • If the app adds or changes permissions after initial consent, users can see new prompts or “Need admin approval” again.
   • For each affected app:
     • Compare the current permissions requested by the app with what is already consented.
     • If new scopes appear, an admin must grant consent again.
5. Ensure the app is not forcing consent every sign-in
   • Some apps are configured to always show a consent prompt (for example, by using prompt=consent or similar behavior).
   • This is not best practice and can conflict with org policies where user consent is disabled.
   • If an app continues to prompt users even after admin consent is granted, contact the app publisher to confirm there is no setting that forces user consent on every sign-in.
6. Confirm a service principal exists and is correctly configured
   • For each client app, there must be a corresponding Enterprise application (service principal) in the tenant.
   • If the service principal is missing or misconfigured, consent and token acquisition can fail with admin-approval errors.
   • Ensure the app appears under Enterprise applications and that permissions and assignment settings are configured there.
7. Consider conditional access and security policies as a separate layer
   • Conditional Access policies do not directly cause consent prompts, but they can block sign-in or token issuance after consent, leading to an impression that consent “didn’t work.”
   • Common issues:
     • Device compliance requirements
     • Location-based restrictions
     • Risk-based policies
   • If users are blocked after consent, review Conditional Access policies targeting:
     • The specific cloud apps/resources the third-party app is calling (for example, Microsoft Graph, SharePoint, OneDrive), or
     • “All cloud apps.”
   • Work with the Entra administrator to either:
     • Ensure clients meet the policy requirements, or
     • Exclude the app or relevant service principals from specific policies where appropriate.
8. Org-wide enablement best practices for trusted apps
   • For apps like Zapier or Missive that should be broadly available:
     1. Have a Global/Privileged Role Administrator perform tenant-wide admin consent for all required permissions.
     2. Ensure User assignment required is set to No for the enterprise app, unless access must be restricted to specific groups.
     3. If user consent is disabled tenant-wide, rely on admin consent only and avoid apps that force per-user consent each time.
     4. Periodically review the app’s permissions; if the vendor adds new scopes, repeat admin consent.
9. Common root causes to check first in this scenario
   • User consent disabled + app forcing user consent.
   • Admin consent granted only for some scopes, but app later requests additional scopes.
   • User assignment required enabled but users/groups not assigned.
   • Missing or misconfigured service principal for the app.

Following these checks across each affected app typically resolves persistent “Need admin approval” prompts and inconsistent access after admin consent.

References:

• Troubleshoot consent issues in Microsoft Entra ID
• Unexpected consent prompt when signing in to an application
• Overview of user and admin consent
• Consent experience for applications in Microsoft Entra ID
• Authentication
• Problems signing in to a Microsoft application
• Corporate account apps registration error: AADSTS90094 - Microsoft Q&A