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.

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.

Four layers, most restrictive wins

Requestability is not one flag. Four 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.

All four default to open, so the model changes nothing for an existing tenant until someone closes something. 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. If no manager is on file, or an owner step has no owner, 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.

Self-approval is marked, not skipped

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.

This is handled per step, not per request. Any step whose resolved approver is the requester is auto-approved on that step and recorded as such: an explicit auto-approved (self) decision, the requester as decider, a timestamp, and a note saying the requester was the configured approver. Every other step stays pending for its own approver — a two-step chain where the requester is the manager keeps its owner step.

Two things make that defensible. It is applied identically to both ways a chain can be built, from one place, so routing configuration cannot produce a chain where the rule holds and another where it does not. And the step stays visible in the trail rather than filtered out of it: a reviewer sees that step one was self-approved and by whom, instead of a two-step chain with one decision in it and no explanation of where the other went. Where every step resolves to the requester there is nothing left to decide and the request settles at once — less a loophole than a statement about the configuration.

Two ways an approval becomes access

An approved request has to reach a target system, by one of two configured routes. It is a per-tenant setting, reversible, with no data migration either way.

Eager is the default: on approval the platform calls the provisioning engine directly for each item and records the outcome.

Reconciliation-driven provisions nothing at the point of approval. 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.

The reason to want the second is single-emitter discipline. Reconciliation already computes Expected against Actual and owns every gate a write can meet: connectors that hold writes for batch approval, 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.

Privileged elevation and requesting an account in its own right stay eager under both settings. They are imperative acts, not statements about a steady state — see Privileged access.

In that mode the platform distinguishes an approved request whose access is recorded from one whose access is live. Where the connector holds writes for batch approval or manual review, the request 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. 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.

Known edges, published rather than discovered

In the default eager mode, an item is marked provisioned once the grant is recorded. Where a connector holds writes for batch approval, that status describes our records rather than the target system — the distinct awaiting provisioning state is produced only by the reconciliation-driven mode. If a deployment runs gated connectors, prefer that mode, or read item status as "approved and recorded" rather than "live at the target".
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: