Request flows users actually complete.

Lifecycle

Submission to evidence, in one record.

Every request travels the same five beats. Each beat has a concrete surface — an end-user screen, an approval card, a fulfillment handoff, a journal entry — and each beat writes to the same request record.

Approval patterns

The decision models your policy actually uses.

Each Resource carries its own approval policy. The policy picks the pattern — not the other way around.

Break-glass

Urgent access can start before the approval finishes — not instead of it.

Some access can’t wait for a chain to clear. On a Resource configured for it, a request whose beneficiary already holds a ratified grant can move to fulfillment while a frozen copy of the approval flow runs behind it as retroactive ratification — the approvers still see the request, still decide, and their queue marks it as access that is already live. A Resource marked eligible for break-glass can extend that to a first-time grant, optionally only for named beneficiary groups, and forces a short access window on top: the tightest cap wins, and the grant expires on its own.

This is not a bypass. Blocking policies still park the request in every mode, eligibility is a property of the individual Resource rather than a tenant-wide switch, and the request stays in progress until both fulfillment and ratification have settled. If ratification rejects, the grant that was already fulfilled is revoked through the same provisioning pipeline that created it, and a configurable cooldown holds that beneficiary out of the optimistic path for that Resource — break-glass eligibility does not waive the cooldown. A successful break-glass grant can also open a post-hoc certification for the Resource owner to review independently, and its grant, revocation, and expiry notifications are not suppressed as machine noise. The record carries both halves: what was granted, and what the approvers decided afterwards. Requests that don’t qualify take the standard route.

Chains and delegation

Multi-step approval that doesn’t restart on a snag.

A stage advances only once its quorum is met — one approver, everyone, or N-of-M, with multiple approvers acting in parallel inside the same stage. By default, a rejection stops the chain the moment it makes that quorum unreachable — immediate for a single-approver or all-must-approve stage — though an N-of-M stage can be set to fail on the first rejection instead. Manager-based stages fall back to a named user or group when the beneficiary has no manager record. Policy-driven stages can reassign dynamically, and a reassignment keeps the current stage open under the new assignee rather than advancing the chain. Later stages wait until the current stage resolves.

An approver being away is its own kind of snag. A delegate configured on an approver’s identity — a vacation window with real dates, or a standing assistant arrangement — sees, is notified about, and can decide that approver’s pending approvals. Nothing is reassigned: the ticket stays with the accountable approver, both people can act on it, and every delegated decision records who actually made it and the delegation it was made under.

Notifications

Every status change reaches the right person — once.

Request and approval notifications don’t ride ad-hoc emails scattered across services. They move through one governed pipeline: a typed catalog — request submitted, approved, denied, fulfilled, canceled; ticket assigned — resolved against per-tenant channel policy and each person’s own preferences, over email, in-app, and Slack — where an approver can approve, deny, or reassign in the message itself. Every delivery is tracked per recipient and channel, retried on a backoff, and dead-lettered if it never lands rather than silently dropped. Repeated emissions of the same event collapse to a single message, and a failed notification never changes the state of the request that triggered it.