The status cascade
Access is computed in a fixed order. First the platform works out what the sources grant: policies, roles, approved requests and manual grants, each with its validity. Then a chain of statuses decides whether each of those grants may be in the Expected state right now. What survives is Expected, and reconciliation brings each system in line with it.
A status answers an operational question: is this person locked, is this system in maintenance, is this group being retired? The sources answer a governance question: why should this person have this access? Keeping the two apart is what lets a status end cleanly. A status never deletes or withdraws a source. It only keeps the grant out of Expected, and when the status ends the same sources grant again.
- The sources say what Sara should have: the Finance staff policy grants the ERP finance role through her Finance contract. Whether it may be in Expected depends on the seven links of its chain.
- Every link is active, so the grant is in Expected and reconciliation puts the permission on the ERP system.
- Sara's Finance contract goes on leave, which this tenant maps to locked. That link holds the grant: it leaves Expected and the permission is removed, but the policy and the grant record are kept. This is not drift.
- The leave ends. Nothing special happens: the next reconciliation run computes Expected again from the same source, and the permission comes back.
The chain
A grant reaches Expected only when every link on its chain is active:
| Link | What can stop it | Who sets it |
|---|---|---|
| Entitlement and entitlement type | Its stage: proposed or in approval, deprecated, retired. Or a lock an administrator places on the entitlement or on the whole type. | The catalogue lifecycle; an administrator, with a reason |
| Account | A decision to keep the account off: a manual disable, a rejected account certification, a resolved duplicate. | The person who decided; only an administrator lifts it, with a reason |
| System | Frozen during maintenance or when the system is paused, archived or offboarded. Held when its last sync or connection test failed. | An administrator for maintenance; the platform for held |
| Context or employment row | A status on the department, the contract or the membership the grant came through, such as leave on one contract. | The HR status mapping, the leave process |
| Identity | One of the six behaviour statuses: pending, active, active with no new access, restricted, locked, terminated. | The lifecycle window, HR, the onboarding gate, a security lock |
| Tenant | Suspended, offboarding, an expired trial, a provisioning pause, a restore in progress. | RapidValue or the tenant's administrators |
The identity statuses and the per-contract statuses are explained in JML flows. This page covers the chain as a whole.
Two ways to stop: no new access, or hold
A link that is not active does one of two things.
| No new access | Hold | |
|---|---|---|
| What stays | Everything already granted, and it is restored if it goes missing | Nothing in the target, unless the account itself is disabled |
| What changes | New policy matches wait, shown as "held by status"; requests, JIT elevations and break-glass are refused | The permission leaves the target; the grant record and its reasons stay |
| Examples | An entitlement being deprecated or still in approval; a person under "active, no new access" | A locked or retired entitlement; a locked person; a locked contract |
When a hold ends, nothing special happens: the next reconciliation run computes Expected again from the same sources. Approved requests and manual grants come back with everything else, minus whatever was explicitly revoked, expired or stopped matching in the meantime.
What each level does
Entitlements and their types
A proposed or in-approval entitlement, and one being deprecated, gives no new access: people who hold it keep it, new matches wait. A retired entitlement, or one an administrator locked, holds: the permission is removed from the target and comes back when the lock is lifted. A lock on an entitlement type does the same for every entitlement of that type. A held entitlement never disables anybody's account; the account is still needed for the person's other access.
Accounts
When a person disables an account, an account certification rejects it, or a duplicate is resolved, that decision is recorded on the account and reconciliation will not enable it again, even though policies still want access on it. Several decisions can be open at once; the account stays off until an administrator lifts each of them with a reason. If an account may not be disabled on that system, its permissions are kept out of the target instead, and they come back on the lift.
Systems
A frozen system receives no writes at all: no grants, no revokes, no account changes. A held system, whose last sync or connection test failed, still receives additions but no removals, because the platform cannot be sure what it would remove. Nothing is lost while a system waits: the work shows as waiting and goes out with the first run after the system is writable again.
Contexts and employment rows
A status on a contract or a membership holds only what came through that link. Leave on one contract does not touch what the other contract grants, and a grant that both contracts give stays. See Employments and multi-affiliation.
Identities
A security lock disables the person's accounts. By default the permissions on those accounts stay in place, so a lift restores the person quickly; a tenant can choose to remove the permissions as well. Either way the grants keep their reasons and come back on the lift. Several locks can be open at once, and the person stays locked until the last one is lifted.
The tenant
A frozen tenant writes nothing to its systems and never revokes anything. A state on the supplier's side, such as an expired trial or a suspension, must never take access away in a customer's own systems.
Emergencies cut through, in one direction
An emergency lockout or an AI-agent kill switch may remove access on a frozen system and in a frozen tenant. It never adds anything there. The only exception is a tenant being restored from a backup, where every write waits until the restore is done.
Held access is not drift, and not current access
A grant that its sources give but a status holds is shown as suspended, with the level that holds it. It is compliant while it is absent from the target and is never reported as missing. It also does not count as access the person has: reviews, role mining and separation-of-duties checks read held access as held, even when a lock that only disables the account leaves the permission in place.
Related
- The data model: where the status cascade sits between the reasons for access and the Expected state.
- JML flows: the six identity statuses and where they come from.
- Reconciliation: how Expected and Actual are compared.
- How it fits together: the three loops the cascade is part of.