User Journey: Ask for more access

"I cannot do my job with the access I have." The member asks for a role they do not hold. The journey is done when the request has an answer the member can read: the role is now theirs, or the request was refused and the refusal says why.

Two people act on one request, at different times. The requester is a member: an account of type user, signed in inside one tenant, reading their own record. The trigger is a refusal — a screen answers "permission denied" — or a task the member cannot finish. It starts at My access, which already lists the roles they hold, and it ends when they read the answer.

The answerer is a tenant administrator: an account inside the same tenant that holds iam::roles:assign. The trigger is a request that is waiting. It starts at the tenant's request queue and it ends when the role is granted, or when the request is refused.

This is one journey with two actors, because it is one request with one lifecycle and each actor owns one end of it. The screens stay apart: the member never sees the queue, and the administrator never sees the ask. The administrator's unprompted version of the same write is Change someone's access; here the write answers a request instead of starting one.

A request waits on somebody, so this is the case the user_journey contract calls server-side state. The design first put that state in ores.workflow, as an instance that suspends until somebody answers and resumes when they do. It was landed a different way, and the difference is worth stating because it is the design this document now describes.

A request is a record of its own in ores.inbox, not a step of a run. It has a kind, which says who may decide it and how long it waits; a state; the person who asked; and the reason. Answering it writes a decision beside it, and the two together are its history. Nothing suspends and nothing resumes, because there is no run to suspend: the request is the thing that waits.

Two things followed from that. The engine needed no waiting state, no terminal state per answer and no "a person decides" step kind, because the waiting is a row. And the detail of what was asked for stayed with the component that owns it: an iam.role_grant request is an inbox request plus an IAM row naming the account and the roles, so IAM keeps its own record of a grant and the inbox keeps the queue every kind shares.

The member's rail is not resumable across a reload — only the request is.

Two screens, one per actor. The member's screen is My access, extended by two panels: the ask, which pairs a role picker with the reason, and the requests, which lists what the member has asked for and how each request ended. The four panels answer one question — what may I do, and what have I asked for — so they belong on one screen rather than on a screen of their own.

The administrator's screen is the queue. It shows the requests waiting in the tenant, the selected request in full, and the decision. The decision is one panel because the administrator reads the reason and answers at once; a request that needs research is left in the queue rather than half-answered.

An answered request leaves the waiting list, but it does not leave the screen. The notice that says what happened links back to the request, and a request that vanished would give the administrator nothing to look at, so the queue carries the requests answered within a window below the waiting ones. How long that window is, is the installation's, as the variability system setting inbox.approval_queue.answered_window_seconds.

The queue is the Access group's screen, beside the roster rather than inside it. See who has access answers who is in the tenant; this screen answers what they have asked for.

What was built is these two screens. The member's is MyAccessPage, with the ask in AskForRoleDialog and the member's own list in MyRequests. The administrator's is RequestsPage, which opens a request in RequestDetailPage and shows where it stands with RequestStateChip. The panels are where the design put them; what the design did not settle, and the build did, is that a request is a record the inbox reads rather than an instance both screens watch.

The request is not an IAM record, and it is not a step of a run either. A request waits on a person, so it carries the waiting itself: kind_code says what it is and therefore who may decide it, requested_by is the member, reason is why, state_code is where it has got to — waiting, approved, refused, withdrawn or expired — and expires_at is when it stops waiting.

The kind is what makes the queue one queue. It names the permission a decider must hold and the deadline a request takes, so the inbox can offer the whole tenant's requests without knowing what a role grant is. The detail of this kind is IAM's: role_grant_request names the account and one row per role asked for, keyed by the request. IAM validates the ask against the roles the tenant has put on offer, and that is a rule about roles, which is IAM's to state.

No credential appears on either screen, and nothing either screen carries is a secret: a password, the material a password is checked against, a one-time-secret seed and a service's own secret all stay on the server. The member's ask shows the roles on offer, and the administrator's decision shows the reason — neither needs any of them.

The ask is two subjects because two components own a part of it. IAM owns the question "may this role be asked for", so iam.v1.ops.ask_for_roles is IAM's; the inbox owns waiting, so the request it raises is the inbox's. Nothing suspends, so nothing follows a run's steps.

The story of a request is read through an operation of its own for the same reason the roles are. The entity read of approval requests and the generic history read both gate on the administrator's permission, so the person who raised a request cannot read their own request's versions through either; and the only place a granted role is tied to the request that asked for it is the junction row IAM marks applied. inbox.v1.ops.get_approval_history is entitled to the person who raised the request, so a member reads their own trail and a request they did not raise is answered as absent.

The roles a request asks for are read through an operation rather than through the generated read of role_grant_request_role. That read is gated on iam::role_grant_request_roles:read and IAM isolates those rows by tenant alone, so granting it would let any member read what every other member asked for. iam.v1.ops.get_request_roles is entitled to the person who raised the request and to whoever may read the roles of any, so one read serves the member's own screen and the administrator's queue, and a caller entitled to neither is told the request does not exist.

iam.v1.ops.assign_role checks iam::roles:assign before it writes, so the administrator's decision carries the check the member's ask must not. inbox.v1.ops.expire_overdue_approvals is the one subject here no person calls: the scheduler fires it, so it presents no session, and it closes only what is already past its deadline, which is why that is affordable. The reads a person makes of their own requests and notices are the inbox's, and each is scoped to the person the session names.

This document was written before anything was built, so it listed seven things the journey needed and did not have. All seven are closed. The list is kept because a reader arriving from the older text will have it in mind, and because two of the seven were closed by changing the design rather than by building what the gap asked for.

The deadline and its warning are two behaviours, and they are built as two: the sweep that closes a queue that stopped moving is housekeeping, and the sweep that warns somebody it is about to stop moving is a nudge with its own timing and its own audience. Both are the installation's to schedule, and both are described in Approval request expiry. The warning is raised once per request, and the notice is what says so.

• Know what I may do — where the member reads the roles they hold, which is where the ask starts and where the answer is read.
• Change someone's access — the administrator's unprompted grant, and the assignment the approval writes through.
• Shape the role catalogue — where the role the member asks for is defined, and where the permissions it bundles are decided.
• See who has access — the roster the administrator arrives from, and returns to.
• Sign up — the registration that gave the member the default role this request goes beyond.
• Register a service account — the non-human account that receives roles by assignment and cannot ask for them.

• Registration and Onboarding Defaults — why the default role is a floor and not a ceiling, and why the ask is its own journey.
• Journey execution — the composition classes, and the rule that a journey waiting on a person keeps its state on the server. This journey does, but the state is a request of its own rather than a workflow instance.
• Approval requests — the record that holds the waiting, and the kinds that share one queue.
• The entry journeys — the state table that states the same rule.
• Identity and Access Management
• Role-Based Access Control
• Accounts and Roles — the user guide chapter
• How do I add a PlantUML diagram?
• Access journeys — the group hub

• ores.iam.role — the role asked for and the roles on offer
• ores.iam.account — the member who asks and the administrator who answers
• ores.iam.permission — the codes a role bundles
• ores.inbox.approval_request — where a request waits, and what answered the workflow question
• Approval requests — the record, its kinds, and the rule that answers one
• Approval request expiry — the design of the deadline this journey's gap 7 asked for: the kind's deadline, the two close paths, the sweep that closes what nobody answered, and the sweep that warns the deciders before it does
• Task: Create the role-request journey — the task this document answers
• See the story of a request prototype — the whole journey drawn as one request's story, and what each of the two readers may open
• User Journeys