Access requests
Self-service access is easy to build and easy to get wrong. The failure is rarely the request form; it is everything the form is allowed to ask for. This page describes what a requester sees, what the platform refuses and why, and what "approved" actually means once it has been said.
The catalogue is a filter, not a shop
A requester browses a catalogue of rights, flat or grouped by application. It is not a shop: no prices, no service-level promises, no delivery estimate. It answers one question — what may I ask for — and it answers it by omission.
What a right gives is said where it is chosen. Every list shows a right's type (the tenant's own entitlement type name) and its description, a type filter narrows the views by system and by entitlement, and a right's name opens its details: what permission it is, where it lives, its owner, who approves a request for it and who already has it.
Two independent axes decide what appears. Audience governs who may see a right at all: an entitlement type can name the roles and business groups allowed to request it, an individual entitlement can replace that list, and an empty list means no restriction. Requestability governs whether the thing may be requested by anyone, through the cascade below. Both run through one shared gate used by both catalogue views, so the flat catalogue and the application grid cannot disagree about what is visible, and both are re-checked at submit against the state at that moment rather than the state when the page was rendered.
The filtering is silent, and that is deliberate. A right you may not request is absent — not greyed out, not shown behind a padlock, not shown and then refused. Rendering the forbidden turns the catalogue into a map of the estate and generates a support ticket per entry. Refusal messages exist, but for the narrow case where something was requestable when the page loaded and is not by the time the request arrives: a stale tab, a direct API call, an administrator who closed a system in between. In the interface, absence is the answer. Rights already held are the exception — shown, marked as held, not requestable again.
The end user's Home adds two short lists beside the catalogue, under the same rules:
- Often used in your department: up to four rights that at least five different people in your department asked for in the last 90 days. A person counts once however often they asked, and rejected or cancelled requests do not count. The threshold is applied on the server, so a right below it never reaches the page, and the count itself is never shown. Rights you already hold, directly or through a role, are left out, and so is any right the catalogue would not show you.
- What you have: your own current grants, most recently used first, each with the strongest reason you hold it: a role, a policy, a request, a context, an application, a review, a manual grant, a mover or a found account. Use is shown only where the system reports it; a grant unused for 90 days or more is marked.
Four layers, most restrictive wins
Requestability is not one flag. Five layers each hold a veto, evaluated top down, stopping at the first that says no:
- The system. A connector can be closed to requests entirely. Nothing on it is requestable, whatever sits below.
- The application. If that system belongs to an onboarded application, the application can be closed. Nothing in it is requestable.
- The entitlement type. The default for a whole class of rights.
- The individual entitlement. An override that is deliberately three-valued: unset means inherit the type's default, which is not the same as no. The entitlement's owner can switch it between requestable and not requestable on the entitlement's page; setting it back to inherit, a context-bound entitlement and every other setting stay with an administrator, and the audit record says in which capacity the decision was taken.
- An owner, for a privileged right. A right that is privileged (by risk level or by classification) and has no owner is held from the catalogue until someone owns it: its owner approval step would otherwise fall back to people who do not know the right. A request for it is refused with that sentence, and the shop and the entitlement page say why. An explicit yes on the entitlement itself still wins.
The first four default to open; the fifth only holds privileged rights nobody owns. Since 26 October 2026, an unowned privileged right that used to be in the catalogue therefore disappears from it until an owner is assigned. A layer that does not exist — an entitlement with no system, a system belonging to no application — counts as "does not block" rather than as a refusal; a missing link should never close access by accident.
The cascade is asymmetric on purpose, and the asymmetry is the point. A lower layer can never re-open what a higher layer closed. An explicit yes on a single entitlement overrides its type's default — that is what the override is for — but it cannot reach past the application or the system above it. So a system owner who closes a connector during a migration, or an application owner who freezes a catalogue pending an owner review, need not audit every entitlement underneath to know the decision holds. Were the reverse true, the higher-level control would be advisory: a statement of intent that any one of several hundred rows could quietly contradict. Broad decisions must be enforceable by the people broad enough to make them, or nobody makes them.
A refusal names the layer and the object — "the Aurora Payroll system is closed to requests", not "not available" — and there is exactly one implementation of the decision, so a catalogue listing and the submit path cannot disagree.
Requesting the application, not the group behind it
An application in a real estate is rarely one object. It is four directory groups, a licence and a role in the vendor's own console. Asking a business user which of those they need is how self-service catalogues become unusable — and how they become dangerous, because a user who guesses right has bypassed everything the application's owner put in place.
So when a directory group is placed behind an onboarded application, two things happen together. An application role is minted (or reused) containing the group, and the raw group stops being individually requestable. The business requests the application role; the membership that lands in the directory is identical, the governance around it is not. Roles and policies that already referenced the raw group are re-pointed at the application role at the same time, so access that depended on it stays valid.
Without the demotion both routes stay open and the raw one is weaker: it skips the application's catalogue gate, its labelling and risk overrides, and its approval routing — the request would go to whoever owns the directory group, frequently a platform team with no view on whether this person belongs in the payroll application. The demotion is what makes the application the unit of governance rather than a label over one.
Three properties keep this honest:
- It is reversible. Removing the group restores its requestability — to unset, so it inherits its type's default again rather than being forced open. A group still fronted by another application, or already deprecated on its own lifecycle, is deliberately left demoted: a restore must not undo a decision made elsewhere for another reason. Deleting an application unfronts everything it fronted.
- It never demotes without offering a replacement. Where the platform cannot mint an application role, the group is tagged but not demoted, and the condition is logged loudly. Demoting with nothing to request in its place would leave the business no path at all — worse than the problem being solved.
- There is no retrospective sweep. Nothing demotes groups in bulk and no migration has ever done so. Fronting takes effect as applications are onboarded or extended, or when an administrator runs the repair.
The catalogue has no special case for any of this: a fronted group disappears because the cascade hides it, in the same place and for the same reason as every other refusal. A "hide fronted groups" filter on the read would have been a fifth, undocumented layer that disagreed with submit. The data is fixed, not the view.
What has to be true before an approver sees anything
Submitting is not merely recording an intention. Beyond audience and requestability re-checked point-in-time, two refusals matter.
Segregation of duties is checked before approval, not after. The prospective grants are evaluated against active rules; a blocking conflict refuses the submission outright, naming the conflicting rights. A conflict configured to require approval does not block — it adds a security step and carries the conflict detail into that approver's task, so whoever is asked to accept the combination can see what it is.
An unresolvable approval chain refuses the submission. A step that cannot resolve (no manager on file, no owner) first falls back through the tenant's approval fallbacks and keeps its level. Only when no fallback resolves either, the request is turned away with a list of what is missing. This replaced something worse: an unresolvable chain used to be an empty chain, and an empty chain approved itself and provisioned immediately. A request nobody can approve must fail loudly at the door.
Nobody approves their own request
Approval chains routinely resolve to the requester — a manager requesting for themselves is their own manager's step; an application owner requesting a right in their own application is its owner step. Whoever initiated a request may not approve it, so such a step is not skipped and not auto-approved: it is rerouted before any task exists.
The reroute walks the tenant's own approval fallbacks for that step's slot — for a manager step that is the manager's manager, so responsibility goes up — skipping any candidate that again reaches only the requester, and ends at the IAM team if nothing else qualifies. The step keeps its level, and it says it fell back ("four-eyes fallback") instead of looking like an ordinary step. The same applies to a step whose role nobody holds: it falls back instead of waiting on an inbox nobody sees.
The rule holds on the decision itself, not only at routing: the requester cannot approve their own request, also not as an administrator through the override, and an on-behalf requester is covered as well as the person the access is for. Rejecting or withdrawing your own request stays allowed. Where the requester is the only administrator, the step waits, visibly, for a second administrator. A refused attempt is recorded in the audit trail. The inbox hides the Approve action and gives the reason in words.
How an approval becomes access
Reconciliation is the only route by which an approved request reaches a target system. On approval nothing is provisioned directly. The approved request is written into the identity's Expected state as a request-sourced entry, and a reconciliation run for that identity performs the write. The approval becomes a statement about what should be true; reconciliation makes it true. (Earlier versions offered a per-tenant direct-provisioning mode as the default. It has been removed.)
The reason is single-emitter discipline. Reconciliation already computes Expected against Actual and owns every gate a write can meet: systems that hold a kind of write for review first, systems where a synchronisation relationship means the change must be made at the source, accounts that must exist before membership can be granted, the failed-jobs queue that catches what breaks. Each was implemented once, there. A second route beside it either re-implements those gates or quietly skips them — and quietly skipping them is not a defect anyone notices; it is a connector provisioning immediately in a tenant that believed writes were held for review.
Where reconciliation already expects the same access for another reason — a policy that happens to grant it — the approved request is layered onto that expectation rather than skipped as redundant. Skipped, the access would carry the policy's provenance alone, and the day the policy stopped matching, reconciliation would remove access an approval had granted. Both reasons are kept; both must lapse.
A time-bound request carries its end with it. The end date is written onto the grant and onto the request's entry in Expected, so when the window closes reconciliation removes the access; the platform does not leave it behind as drift. An end date given as a day lasts until midnight of that day in the tenant's time zone (set under Governance settings, Business defaults; Europe/Brussels by default). A window whose end has already passed, or does not come after its start, is refused when the request is submitted.
A rejection needs a reason: the approver types a note before Reject is available, so the requester always learns why. A business role that is not yet active (still in approval, for example) is not offered as a starting point for a request.
Privileged elevation (just-in-time sessions) and requesting an account in its own right stay imperative. They are acts, not statements about a steady state — see Privileged access.
The platform distinguishes an approved request whose access is recorded from one whose access is live. Where the system holds that kind of write for review first (an account create counts too), the item settles as awaiting provisioning: fully approved, grant written, push not yet made, with the batch it waits on named. To the requester that reads as still in flight, not as granted. Access that has not reached the system is not access, and a status saying otherwise is the one thing self-service must not do. Once reconciliation sees the access in the target, the item moves forward to provisioned, including an item that had been marked failed or awaiting; it never moves back. An item whose write genuinely fails is marked failed and linked to a job in the failed-jobs queue, so the requester sees it failed and being retried while operations get the diagnosis and a controlled retry. A provisioning error during the decision does not turn the approval into an error page: the item fails with its linked job. A failed account create names the reason the target gave and removes the stub account it left behind, so reconciliation does not keep asking for the create again.
A withdrawn or rejected request also takes back what it never delivered: a queued grant and a stub account created for it are released, so reconciliation does not keep trying to create the account.
A group that grants a platform role is not a back door. An approved request for a group that makes someone, for example, an IGA administrator is provisioned only when its final approver could make the same change in Platform access. Otherwise, and also when no person approved it, the item fails with the reason, nothing is written and the refusal is audited. Business groups are not affected.
Requests made for you show up for you. My requests has a For me tab with what other people requested for you: what, by whom, when and its status, without their justification. Someone who may request for a colleague sees that colleague's approval chain on the review page before submitting, as they would for themselves.
Known edges, published rather than discovered
- The approval chain is fixed at submit. It is not editable afterwards; the route for a mistake is to cancel and re-submit. The chain that was evaluated is the chain that executes, at the cost of no mid-flight correction.
- A group is only fronted once someone fronts it. Estates onboarded before an application existed keep their raw groups requestable until that application is onboarded, extended or repaired.
- Requestability is not authorisation. The cascade governs what may be asked for; whether it is granted is the approval chain's decision, and whether it stays granted belongs to reconciliation and the access reviews.
Further reading: