Entitlement Management: Catalogs & Access Packages
Plan entitlements, create and configure catalogs and access packages to streamline how users request and receive access to resources.
What is Entitlement Management?
Entitlement management is like a restaurant menu system for access.
Imagine a hospital cafeteria. Instead of letting everyone walk into the kitchen and grab whatever they want, you create a menu (catalog) with combo meals (access packages). A “Clinical Researcher Combo” might include access to the research SharePoint, the lab results app, and the data analysis Teams channel — all bundled together.
Staff browse the menu, request what they need, a manager approves it, and the system delivers everything at once. When the project ends, access is automatically cleaned up. No more chasing IT for five separate access requests.
The building blocks
Entitlement management has a clear hierarchy. Understand this and the exam questions become straightforward:
| Component | What It Is | Analogy |
|---|---|---|
| Catalog | Container that groups resources together | The menu |
| Resource | A group, app, or SharePoint site added to a catalog | An individual ingredient |
| Access package | A bundle of resource roles users can request | A combo meal |
| Policy | Rules for who can request, approval flow, and expiration | The ordering rules |
| Assignment | A user’s active access to a package | A served order |
Catalogs — organising your resources
A catalog is a container of resources and access packages. Think of it as a boundary for delegation — you can make a department head the catalog owner so they manage their own resources without needing global admin rights.
Key facts about catalogs:
- The General catalog is created automatically — it’s the default catch-all
- You can create additional catalogs to separate resources by department, project, or partner
- Catalog roles: Owner (full control), Reader (view only), Access package manager (create/manage packages), Access package assignment manager (manage assignments)
- Resources must be added to a catalog before they can be included in access packages
Scenario: Priya creates a Clinical Research catalog
🔐 Priya Sharma at Meridian Health needs to manage access for 200+ clinical researchers across multiple projects. Instead of handling each request individually, she creates a Clinical Research catalog.
She adds these resources to the catalog:
- Clinical Data Analysts security group (gives access to the data warehouse)
- Research Portal enterprise app
- Clinical Studies SharePoint site
She then assigns Dr. Chen (head of research) as a catalog owner. Now Dr. Chen can create access packages and manage assignments without involving IT for every request.
Exam tip: Catalog owners can manage everything in their catalog, but they can’t create new catalogs unless they have the Catalog creator role, the Identity Governance Administrator role, or are a Global Administrator.
Access packages — the combo meals
An access package bundles one or more resource roles from a single catalog. Users request access packages through myaccess.microsoft.com — the self-service portal.
What goes into an access package:
- Resource roles — which resources and what level of access (e.g., Member of a group, User role on an app)
- Policies — one or more policies that define:
- Who can request — specific users/groups, all members, connected organisations, or anyone
- Approval — none, single-stage, or multi-stage approval
- Expiration — never, specific date, or number of days after approval
- Access reviews — periodic review of who still needs access
Scenario: Building the Research Analyst access package
🔐 Priya creates an access package called Research Analyst Access in the Clinical Research catalog:
Resource roles included:
- Clinical Data Analysts group → Member
- Research Portal app → User
- Clinical Studies SharePoint → Member
Policy settings:
- Who can request: Members of the “Research Department” group
- Approval: Required — first Dr. Chen, then Priya as fallback
- Expiration: 365 days (researchers must re-request annually)
- Access review: Every 90 days, reviewed by the user’s manager
Now when a new researcher joins, they go to myaccess.microsoft.com, request the Research Analyst Access package, Dr. Chen approves, and the researcher gets all three resources automatically. After 365 days, access expires unless renewed.
Approval workflows
Access packages support flexible approval:
| Approval Type | How It Works | Best For |
|---|---|---|
| No approval | Automatic — request = instant access | Low-risk resources, internal teams |
| Single-stage | One approver must approve | Standard departmental access |
| Multi-stage | First approver → then second approver | Sensitive resources, compliance-heavy environments |
Each stage can have:
- Specific approvers (named users)
- Manager as approver (the requestor’s manager)
- Sponsor as approver (connected org sponsor)
- Fallback approvers if the primary doesn’t respond within the timeout
Exam tip: Requestor justification
Policies can require a justification from the requestor. This is a free-text field where the user explains why they need access. The justification appears in the approval request and in audit logs — important for compliance.
The exam may test whether justification is required by default (it’s not — you must enable it in the policy).
Automatic assignment policies
Beyond request-based access, you can create automatic assignment policies that grant access based on user attributes — no request needed.
For example: “All users where Department = Research AND jobTitle contains ‘Analyst’ automatically get the Research Analyst Access package.”
This uses the same attribute-based rules as dynamic groups. When a user matches the rule, they get the package. When they no longer match (e.g., they change departments), access is automatically removed.
Exam tip: Automatic vs request-based
An access package can have both automatic assignment policies and request-based policies simultaneously. Automatic policies are great for baseline access, while request-based policies handle exceptions and special cases.
Separation of duties
Entitlement management supports incompatible access packages — you can mark two packages as incompatible so a user can’t hold both simultaneously.
Example: A user can’t have both “Financial Auditor Access” and “Financial Data Entry Access” — that would violate separation of duties.
If a user already has Package A and requests incompatible Package B, the request is blocked.
| Feature | Catalogs | Access Packages |
|---|---|---|
| Purpose | Organise and delegate resources | Bundle resource roles for request |
| Contains | Resources + access packages | Resource roles + policies |
| Who manages | Catalog owners, Global Admin, Identity Governance Admin | Access package managers, catalog owners |
| User-facing | No — admin concept only | Yes — visible in myaccess.microsoft.com |
| Limit | 7,500 per tenant | 20,000 per tenant |
Video Lesson
🎬 Video coming soon
Entitlement Management: Catalogs & Access Packages
Entitlement Management: Catalogs & Access Packages
~10 minKey Concepts
Knowledge Check
Priya needs clinical researchers to automatically receive access to the research portal, data warehouse group, and SharePoint site when they join the Research department — without submitting a request. What should she configure?
Jake at Coastline Creative wants to bundle access to the Design Tools app, Creative Assets SharePoint site, and the Designers group into a single requestable package. He's already created a catalog with these resources. What should he create next?
Meridian Health's compliance team requires that no employee can have both the 'Financial Auditor' and 'Financial Data Entry' access packages at the same time. How should Priya enforce this?
Next up: Access Requests, Terms of Use & External Lifecycle — how to manage the request experience, enforce terms of use, and control the lifecycle of external guest users.