Administrator guide
Access bundles
Build sets of access that are requested, approved and granted together, and birthright bundles your joiner process grants.
An access bundle is a set of entitlements given together, such as everything a new accounts payable officer needs. A bundle has an owner, an approval policy, and a version that goes up every time its contents change.
| Bundle type | How people get it |
|---|---|
| Requestable | People ask for it with the Access Bundles form, for one or more people at once |
| Birthright | Your joiner process grants it through the lifecycle API. It never appears on a request form. |
Pre-approval
When a bundle is built, each entitlement's owner is asked once whether it may be included. An approved entitlement is then granted with the bundle without its own approval. A request for the bundle still runs the bundle's approval policy.
| Pre-approval state | Meaning |
|---|---|
| Pending | Waiting for the entitlement's owner |
| Approved | The owner agreed. Requests for the bundle grant it with no further approval. |
| Rejected | The owner refused. It is not granted with the bundle. |
| Restricted | It cannot be pre-approved, so each request for the bundle also runs this entitlement's own approval |
An entitlement is restricted when its own pre-approval mode is Never. Left empty, it follows its collection, except that high-risk and licence-bound access is restricted unless the entitlement itself says Allowed.
Some entitlements cannot be added to a bundle at all: deprecated or retired ones, ones that must have an end date, and PIM-managed groups.
Build a bundle in the Admin Workspace
- Open Catalog > Access bundles in the Admin Workspace and create a bundle. Give it a name, a description requesters will understand, an owner, a type, and optionally an approval policy and an audience. With no policy, requests use the instance default.
- Add entitlements on the bundle's related list. To start from someone's current access, set Copy access from to a person and select Copy access from user.
- Select Submit for pre-approval. Each entitlement owner gets the email Access bundle items waiting for your approval and decides with Approve inclusion or Reject inclusion.
- When nothing is pending, the owner gets Your access bundle is ready to activate. An administrator selects Activate. The bundle never goes live by itself.
Withdraw takes a submitted bundle back to draft. Retire closes a bundle for good. An administrator can Resubmit for pre-approval or Remove from bundle on a single entitlement.
Propose a bundle with a request
Anyone with the requester role can propose a bundle with the Onboard an Access Bundle catalog item: a name, what it is for, an owner, how people get it, the access in it, and what approval requests for it should need.
The proposal is approved by the bundle approvers group, x_66256_warde.admin.group. If that group is unset or empty, Warde asks the fallback fulfilment group, then the Warde administrators directly. The entitlement owners' pre-approval follows on the same request. Warde then creates the bundle in draft, and an administrator activates it.
Change a live bundle
There are two ways to change what a live bundle gives:
- An administrator edits it in the Admin Workspace. A new entitlement goes to its owner for pre-approval, and new requests include it once approved; the bundle owner is told. A removal takes effect for new requests straight away.
- Anyone proposes a change with the Onboard an Access Bundle form, choosing to amend a live bundle. What comes out is approved under the bundle's own approval policy, or by its owner if it has none. What goes in is approved by each entitlement's owner. An amendment that would empty the bundle is refused: retire the bundle instead.
Each change raises the version. People who hold an older version are shown as behind, and the owner is emailed once per version. Select Update people who have it to bring them onto the current version. Warde raises one request per holder, and only additions that are restricted need approval.
Removing a bundle
People give a bundle back whole with the Remove Access Bundles form, or with Remove Access beside it on My Access. A single entitlement that came in a bundle cannot be removed on its own; Warde tells the person to remove the bundle. A birthright bundle cannot be removed by a request, because the next lifecycle call would grant it again: change the rule or the HR details that give it.
In an access review, a requestable bundle can be kept or removed. A birthright bundle can only be kept.
Bundles and the access your engine automates
If your identity platform already grants some access by its own rules, leave that access out of the bundle, and leave out the platform's own birthright role. The bundle then holds what the platform does not grant, usually the manual remainder. Warde still shows the platform's rule-given access on My Access and in reviews, named as given by a rule in the connected system.