Enterprise Apps: Users, Consent & Collections
Assign users and groups, manage consent frameworks, configure app roles, and organise enterprise applications into collections in Microsoft Entra ID.
Understanding consent in Entra ID
Consent is like a permission slip for apps.
When an app says “I’d like to read your calendar” — someone has to say yes. In a school, kids can sign basic permission slips themselves (user consent), but a trip to another country? That needs a parent signature (admin consent).
In Entra ID, low-risk permissions (like reading your own profile) might be approved by users themselves. But high-risk permissions (like reading everyone’s email) need an admin to approve. The admin consent workflow is the process where a user says “I need this app” and an admin reviews the request.
The consent framework
User consent vs admin consent
| Aspect | User Consent | Admin Consent |
|---|---|---|
| Who approves | The individual user | A Global Admin or Cloud Application Admin |
| Scope | Only for that user’s data | For the entire organisation |
| Permission types | Low-risk, delegated permissions only | Any permission, including application-level |
| Risk level | Lower (limited scope) | Higher (organisation-wide impact) |
| Control | Can be restricted or disabled by admins | Always available to admins |
Consent settings — the three options
In Entra admin center → Enterprise applications → Consent and permissions → User consent settings, you choose one of three options:
| Setting | What Happens |
|---|---|
| Do not allow user consent | Users can never consent. Every app requires admin consent. Most secure but creates bottleneck. |
| Allow user consent for apps from verified publishers, for selected permissions | Users can consent only if the app publisher is Microsoft-verified AND the permissions are in your allowed set. Recommended balance. |
| Allow user consent for all apps | Users can consent to any app for any delegated permission. Least secure — not recommended. |
Exam tip: Verified publishers
Verified publishers are app developers who have verified their identity with Microsoft using their Microsoft Partner Network (MPN) account. A blue “verified” badge appears on the consent prompt. The recommended consent setting limits user consent to verified publishers only — this dramatically reduces the risk of illicit consent grant attacks while still allowing employees to use trusted apps.
Admin consent workflow
The admin consent workflow bridges the gap between “no user consent” (too restrictive) and “all user consent” (too risky):
User tries to access an app
↓ Consent required but user can't consent
User submits a consent request (with justification)
↓ Notification sent to designated reviewers
Admin reviews the request
↓ Approves or denies
If approved → admin consent is granted for the org
↓ User (and everyone assigned) can now access the appConfiguring the workflow:
- Entra admin center → Enterprise applications → Admin consent settings
- Enable Users can request admin consent to apps they are unable to consent to
- Select reviewers (specific users or roles — e.g., Cloud Application Administrators)
- Set notification options (email notifications to reviewers)
- Set request expiry (how long before unanswered requests expire)
Scenario: Priya manages the consent workflow at Meridian Health
🔐 Priya Sharma at Meridian Health needs to balance security with productivity:
- Problem: Developers keep requesting apps that need Graph API access. With user consent fully disabled, every request goes to the Global Admin — who has a 3-day backlog.
Priya’s solution:
- Sets user consent to “Allow for verified publishers, for selected permissions” — covers low-risk apps automatically
- Enables the admin consent workflow with Cloud Application Administrators as reviewers
- Sets request expiry to 30 days
- Adds email notifications so reviewers are alerted immediately
Result: Employees can self-serve for verified, low-risk apps. Unknown or risky apps trigger the workflow. Priya’s team reviews requests within 24 hours instead of 3 days. Illicit consent grant risk is dramatically reduced.
Assigning users, groups, and app roles
User and group assignment
When “Assignment required?” is set to Yes on an enterprise app, you control access by assigning:
- Individual users — direct assignment for small teams
- Security groups — recommended for scale (assign one group, manage membership separately)
- M365 groups — works too, but security groups are more common for app access
Assignment steps:
- Enterprise application → Users and groups → Add user/group
- Select users or groups
- Select a role (if app roles are defined) — otherwise “Default Access” is assigned
- Click Assign
App roles
App roles let you define custom permission levels within an application. Instead of just “can access” or “can’t access,” you get granular control:
| Example App Role | Description | Who Gets It |
|---|---|---|
| Admin | Full access to all features | IT administrators |
| Editor | Can create and edit content | Department managers |
| Viewer | Read-only access | General staff |
| Auditor | Can view audit logs only | Compliance team |
App roles are defined in the app registration (developer side) and assigned in the enterprise application (consumer side).
Scenario: Jake assigns app roles at Coastline Creative
🏪 Jake Torres at Coastline Creative has a project management SaaS app with three roles: Admin, Project Manager, and Viewer.
- Jake opens the enterprise app → Users and groups
- Assigns himself the Admin role
- Assigns the “Design Team” group the Project Manager role
- Assigns “All Staff” group the Viewer role
When a designer signs in, the app receives a token with the claim roles: ["ProjectManager"]. The app uses this claim to show the right features. When an intern signs in, they get roles: ["Viewer"] — they can see projects but can’t edit them.
Exam tip: Where roles are defined vs assigned
This is a common exam confusion:
- App roles are defined in the App registration → App roles blade (developer side)
- App roles are assigned in the Enterprise application → Users and groups blade (admin side)
- Roles appear as claims in the token — the application reads these claims to enforce authorisation
Application collections (My Apps)
Application collections organise apps in the My Apps portal (myapps.microsoft.com) into logical groups so users can find what they need quickly.
Without collections: Users see a flat list of 50+ apps — confusing and hard to navigate. With collections: Apps are grouped into tabs like “HR Tools,” “Finance,” “Engineering,” “Training.”
Creating collections
- Entra admin center → Enterprise applications → App launchers → Collections
- Click New collection
- Name the collection (e.g., “Finance Tools”)
- Add applications to the collection
- Assign users or groups who should see this collection
Key points:
- Each collection is visible only to the users/groups assigned to it
- An app can appear in multiple collections
- Collections support a default collection where unorganised apps appear
- Collections use Entra ID P1 or P2 licence
Scenario: Priya organises My Apps for Meridian Health
🔐 Priya creates collections for Meridian Health’s 5,000 staff:
| Collection | Apps | Assigned To |
|---|---|---|
| Clinical | Epic, PACS Viewer, Lab Portal | Clinical Staff group |
| HR & Finance | Workday, Concur, SAP | HR group, Finance group |
| IT Tools | ServiceNow, Intune, Azure Portal | IT Staff group |
| Everyone | Teams Web, SharePoint, Outlook Web | All employees |
Result: A nurse logging into My Apps sees “Clinical” and “Everyone” tabs — not 50 apps they’ll never use. An HR analyst sees “HR & Finance” and “Everyone.” Clean, relevant, role-appropriate.
🎬 Video walkthrough
🎬 Video coming soon
Consent, App Roles & Collections — SC-300 Module 18
Consent, App Roles & Collections — SC-300 Module 18
~11 minFlashcards
Knowledge Check
Priya wants to allow Meridian Health staff to consent to low-risk apps from trusted publishers, but require admin approval for everything else. What should she configure?
Jake at Coastline Creative has a project management app with Admin, Project Manager, and Viewer roles. Where does Jake define these roles, and where does he assign them to users?
A user at Meridian Health tries to use a new analytics app. The consent prompt says the app wants to 'read all users' mailbox contents.' The app publisher is NOT a verified publisher. What happens if Priya has configured the recommended consent settings?
Next up: App Registrations: Build & Secure — how to register custom applications, configure authentication, API permissions, and app roles from the developer side.