Someone at a partner firm asks for access, the invitation goes out on its own, and the account is gone the day the project closes.
The idea is simple enough. Groups, Teams, applications and SharePoint sites are gathered into a package. People ask for the package, a named person approves it, and the approval carries an end date. Where the requester sits outside your organization it goes further still: approve somebody who is not yet in the directory and the invitation is issued automatically, and when the access runs out with nothing else assigned to them, the guest account itself can be taken away without anyone remembering to do it.
- Access packagesGroups, Teams, apps and sites bundled
- Time-limitedAssignments expire unless renewed
- Auto-inviteAnd automatic B2B account removal
- DelegatedCatalog owners create their own packages
Eight things it does, and the handling of external accounts is the one with no substitute.
External identities invited and removed automatically
Approve a request from somebody who has never existed in your directory and they are invited in and granted the access in the same motion. When that access runs out, provided nothing else is assigned to them, the guest account can be deleted automatically. That is the loop which, left open, leaves tenants carrying guest accounts from projects that finished three years ago.
Access packages that bundle everything a role needs
What can go inside one: security group membership, membership of Microsoft 365 Groups and Teams, assignment into enterprise applications whether purchased as software or built in house, provided they support federation, single sign-on or provisioning, and membership of SharePoint sites. Currently in preview are API permissions for agent identities and SAP business roles.
Time-limited by default rather than by exception
Nothing is meant to be held forever, which is why assignments carry a clock and reviews come around on a schedule. The policy on the package sets how long an approved assignment survives. That is the structural difference from a plain group: membership of a group lasts until a human takes it away, whereas an assignment lasts until the date arrives.
Multi-stage approval, defined per policy
Every policy names the approval path and the people entitled to say yes or no, and approval can run in stages. One package can hold two policies at once, so staff request it under one set of terms and people from a partner directory request the same package under another. That is how a single bundle serves two very different audiences without being built twice.
Catalogs, which is how you delegate without losing control
Catalogs hold related resources and packages together, and they exist so people who are not administrators can build their own packages. The boundary is drawn carefully: an administrator can put anything into any catalog, while everybody else can only contribute resources they already own. Whoever owns a catalog can bring in co-owners or appoint managers for individual packages.
Automatic assignment based on identity properties
Access can also attach itself according to attributes such as department or cost center, and detach when those attributes change. An administrator can assign directly, or a lifecycle workflow can do it. That handles the access which ought to follow the job rather than be asked for, without pushing everything through a request form nobody wants to fill in.
Indirect control over licenses, Azure and Entra roles
Since a security group can sit inside a package, the package inherits everything that group can reach. Three routes in particular: licenses via group-based licensing, control of Azure resources via a role assignment on the group, and directory roles via a group made assignable to them. That is a considerably wider reach than most people assume a package has.
Connected organizations, so partners are a defined set
A connected organization is an outside directory or domain you have an actual relationship with, and its people can be named in a policy as entitled to request. That converts partner access from a scatter of one-off invitations, each sent by whoever happened to need something that week, into a defined relationship with an owner attached to it.
Nobody in either organization knows who should have access.
The problem is set out plainly in the documentation, and it lines up with what we find in every American company that works alongside contractors, vendors or joint venture partners.
- People frequently have no idea what access they should hold, never mind what their team or the automated agents they sponsor should hold, and even when they do know, working out who is entitled to approve it is its own small research project.
- And once it has been tracked down and granted, it tends to stay granted long after the reason for it has gone. That is standing access described in a single sentence.
- With outside parties it is worse again. Nobody on your side knows every individual in the other company directory well enough to invite them properly, and nobody on their side is going to remember to tell you when one of those people leaves.
- More discipline is not the fix. The fix is a package the partner asks for, an approver written into the policy rather than located by asking three people who might know, and an end date that removes the access regardless of whether anybody remembers it exists.
Four things that decide whether this is still usable in its second year.
We design catalogs before packages
Delegation is drawn at the catalog, and anybody who is not an administrator can only contribute resources they already own. Settling that shape first is what makes it possible for departments to run their own packages later on. Building packages and then trying to fit catalogs around them afterward is rework, and nobody enjoys it.
We prove expiry before we build the second package
The whole point is that access stops. So we let one run out deliberately and watch, including what happens to the guest account when the requester came from a connected organization and has nothing else assigned. Until somebody has actually seen that, it is an assumption rather than a control.
We keep packages coarse enough that people use them
A package ought to correspond to something a person would recognize by name: a project, a client engagement, a role. Turning every individual resource into its own package produces a catalog nobody can find anything in, and once requesting becomes harder than emailing the help desk, people go back to emailing the help desk and the whole exercise was pointless.
External access comes first because that is where it actually hurts
The way the documentation frames the outside-identity problem matches what we see in every American company dealing with contractors, vendors and joint ventures. Invitation on approval and account removal on expiry answer something that has no other decent solution, which is exactly why it is the scenario that wins internal backing for everything after it.
Four phases, and phase one is deliberately narrow.
- 01Weeks 1 to 2
Catalogs and the first scenario
Check the licensing first, because this needs Entra ID Governance or the Entra Suite, though a few pieces will run on P2. Then design the catalogs, since that is where delegation is drawn and rearranging it afterward is genuinely disruptive. The opening scenario is picked for what it is worth, not for how easy it looks.
- License position confirmed against the tenant
- Catalog structure agreed with named owners
- Catalog creator list kept deliberately short
- First scenario chosen, usually partner or contractor access
- 02Weeks 3 to 4
The first package, end to end
A single package holding the actual resources that scenario requires, plus a policy stating who is allowed to ask, who approves, and how long the result survives. Where the people asking are outside the company, the connected organization is set up first, so that an approval produces an automatic invitation instead of somebody manually adding a guest.
- Package built with real resources, not placeholders
- Approval chain named, including multi-stage where needed
- Assignment duration set deliberately
- Connected organization configured for external requesters
- 03Weeks 5 to 8
Prove the expiry, then widen
This is the part almost nobody does. We let an assignment run to its end date on purpose and watch the access disappear, and where the requester came from outside and holds nothing else, we watch the guest account go too. Only then do we build anything more, because until the expiry is observed the entire design rests on an assumption.
- Expiry observed end to end, not assumed
- External account removal behavior confirmed
- Renewal path tested from the user side
- Second and third scenarios modeled
- 04Ongoing
Delegate and review
Catalogs are handed to the departments that actually own the resources in them, package managers are named, and recurring reviews are attached to assignments so recertification happens inside this model rather than as a separate annual scramble in a spreadsheet. IT keeps the platform, the business keeps the decisions.
- Catalog owners and package managers trained
- Recurring reviews attached to assignments
- Automatic assignment rules where access should follow a job
- A named owner for the entitlement model itself
Six situations the documentation calls out, and how each one actually turns up.
Two organizations collaborating on a project
This one is listed outright: several people from one company needing to reach another company resources through B2B. A joint venture, a general contractor and their subs, a client and the firm advising them. The package fixes what the partner receives, the connected organization fixes who is entitled to ask, and the end date fixes when it all stops.
Access that requires a manager or designated approver
The published list covers access needing sign-off from a line manager or other named individuals. In regulated American firms that is usually a control obligation rather than a preference, and staged approval lets the manager and the data owner each sign in turn without one of them chasing the other around by email for a week.
Departments that want to manage their own access policies
Also on the list: departments wanting to run access policy for their own resources without going through IT. Catalogs and package managers make that safe, because somebody who is not an administrator can only contribute what they already own. The department gets its independence, IT keeps the platform, and nobody has to trade one for the other.
Time-limited access for a particular task
The worked example in the documentation is a good one. Give everybody a mailbox through a dynamic group and group-based licensing, then use packages for anything extra, such as reading another department material. Permanent access by rule, additional access by package. That split is the one that keeps working as the company grows.
Access that ought to arrive with the job, while still being available on request
There is a category for access that should attach itself to anybody working in a particular part of the business for as long as they are there, while still being requestable by people elsewhere or at a partner firm. Attribute-driven assignment on something like department or cost center handles the first half of that, and the request policy handles the second.
Migrating from a third party role management product
It heads the list of suitable scenarios: moving access policy out of a third party role management product and into Entra. Companies still carrying an aging governance tool, usually bought during a compliance push some years back, get a way to consolidate onto something they are already paying for.
How US organizations grant project and partner access today.
| Feature | Entitlement management | Tickets and manual grants | Ad hoc, no process |
|---|---|---|---|
Access requested through a defined route | Yes | Yes | No |
Approver defined in advance | Yes | Sometimes | No |
Multi-stage approval available | Yes | Rarely | No |
Access expires without intervention | Yes | No | No |
External users invited automatically | Yes | No | No |
External accounts removed on expiry | Yes | No | No |
Business owns the decisions | Yes | No | No |
One request grants everything the role needs | Yes | Rarely | No |
Recertification built into the model | Yes | No | No |
IT effort per grant | None | High | Low but unmanaged |
Ten terms, because the documentation assumes you know them.
Term
Access package
- What Microsoft says it is
- The set of resources a project or a team actually needs, wrapped in policy and always sitting inside a catalog
- Why it matters
- This is what people ask for. Pitch the size wrong and you end up with either five of them or five hundred
Term
Access request
- What Microsoft says it is
- Somebody asking for what is in a package, normally routed through an approval step
- Why it matters
- Approve it and an assignment is created. That is the moment an auditor can point at
Term
Assignment
- What Microsoft says it is
- Confirms the person holds every role the package carries, and normally carries a date it stops
- Why it matters
- The end date is the entire reason this exists. Without one you have simply joined a group
Term
Catalog
- What Microsoft says it is
- Where related resources and packages live together, and the unit you delegate
- Why it matters
- Your delegation boundary. Design these before you design packages
Term
Catalog creator
- What Microsoft says it is
- The people allowed to make new catalogs, each of whom owns whatever they create
- Why it matters
- Keep this list short and chosen on purpose. It is a governance position, not a shortcut for the IT team
Term
Connected organization
- What Microsoft says it is
- An outside directory or domain you actually deal with, whose people can be permitted to make requests
- Why it matters
- Turns ad hoc partner invitations into a managed relationship
Term
Policy
- What Microsoft says it is
- The rules covering how somebody gets in, who signs it off, and how long it lasts
- Why it matters
- A single package can hold more than one, which is how staff and outsiders end up on different terms
Term
Resource
- What Microsoft says it is
- Something you can grant, whether a group, an application or a SharePoint site, together with a role on it
- Why it matters
- What actually goes in the package
Term
Resource directory
- What Microsoft says it is
- Any directory holding something worth sharing
- Why it matters
- Relevant in multi-tenant estates, which acquisitive US groups frequently are
Term
Resource role
- What Microsoft says it is
- The permission set the resource itself defines. On a group that means member or owner
- Why it matters
- Packages hand out roles rather than plain membership, and owner is a very different thing from member
Five steps, starting narrower than most people expect.
- 1
Confirm entitlement and choose the first scenario
This needs Entra ID Governance or the Entra Suite, with a few capabilities working on P2, so the tenant gets checked before anything else. Then a single scenario is chosen on the basis of what it is worth rather than how quick it looks, which in most American companies means contractor or partner access.
- 2
Design the catalog structure
Catalogs group related resources and packages, and they are where delegation is drawn. We settle how many there will be, who owns each one, and the deliberately short list of people allowed to create more. It is the decision that costs the most to revisit later, so it gets the time now.
- 3
Build one package end to end
Actual resources, not stand-ins. Security groups, Microsoft 365 Groups and Teams, enterprise applications and SharePoint sites, whichever the scenario calls for. Then the policy on top: who is entitled to ask, the approval chain including staged approval where it belongs, and how long an assignment lives before it ends.
- 4
Prove request, approval, expiry and removal
That includes the outside path where it applies: somebody approved who has never been in the directory getting invited automatically, and on the end date, with nothing else assigned, the guest account being removed as configured. We sit and watch that happen rather than taking the documentation at its word, because the expiry half is the half that carries the value.
- 5
Widen, delegate and attach reviews
More scenarios get built, catalogs pass to the departments that own what is in them, package managers are appointed and shown how it works, and recurring reviews attach to assignments so recertification happens here rather than as a separate annual project with its own spreadsheet.
What US organizations ask about entitlement management.
Fifteen questions that decide the design.
Structure
- How many catalogs, and owned by whom?This is the delegation boundary.
- What granularity is a package?Per project, per role, or per resource.
- Which resources go in the first one?Groups, Teams, apps and SharePoint sites can mix.
- Do any packages need role-assignable groups?That is how Entra roles get in.
- Is group-based licensing in play?A package can grant licenses indirectly.
Requesting and approving
- Who is eligible to request?Internal identities, or a connected organization.
- Single or multi-stage approval?Microsoft supports multi-stage.
- Who approves when the approver is away?Design it, do not discover it.
- Should some access be automatic instead?Based on department or cost center.
- Is a justification required?It changes what an audit sees.
Ending access
- How long is an assignment?The policy sets it explicitly.
- What is the renewal experience?Test it from the user side.
- Should external accounts be removed on expiry?Only if no other assignments remain.
- Are reviews attached to assignments?Recertification inside the same model.
- Who notices if nothing ever expires?Somebody has to own the model.
The pages around this one.
Entra ID Governance
The suite entitlement management belongs to, and the license it requires.
Entra access reviews
Recertification of package assignments and everything else Entra governs.
Privileged Identity Management
Elevation only at the moment it is needed, for the administrative rights a package has no business holding permanently.
Take the partner access problem nobody has ever managed to fix, and build it as a single package.
Nearly every company has one relationship where access was handed out years ago and nobody today can say who still has it. Start there, because that is precisely where automatic invitation and automatic removal earn their keep.
Related Services
Explore more solutions that work great with this service
Microsoft Entra Lifecycle Workflows
Entra lifecycle workflow implementation for US organizations: joiner
Learn moreMicrosoft Entra ID Governance
Entra ID Governance implementation for US organizations: automating
Learn moreMicrosoft Entra Access Reviews
Entra access review programs for US organizations: entitlement
Learn moreMicrosoft Entra Privileged Identity Management
Privileged Identity Management deployment for US organizations:
Learn moreMicrosoft Entra Conditional Access Design
Conditional Access design and review for US organizations:
Learn moreMicrosoft Entra ID P1 and P2 Licensing Review
Independent Entra ID P1 against P2 advice for US organizations:
Learn more