## When to use

When a user clicks a link or opens a resource they don't have permission to see. Hard-403 the resource but offer a path to ask the owner — better UX than a dead end. The owner gets a notification (15d) + an entry in their approval queue (13d); the requester gets a pending state until the request resolves.

## Access denied — with Request CTA

The standard access-denied state (cross-ref 36d) augmented with a "Request access" primary action. `alert-ui variant="warning"` carries the explanation; the CTA opens the request form.

You don't have access to this
Q4 product roadmap is restricted. Owned by Avery Chen. Ask them for access, or check if your team has a different version.

## Request form

The form the requester fills. Pre-fills the resource being requested; user picks the role they need + optional reason. Submit fires a notification to the owner.

Request access Avery Chen will be notified
Viewer — read only Commenter — read + comment Editor — read + edit

## Pending status

The state the requester sees after submission. `alert-ui variant="info"` with the reviewer name + reasonable ETA. "Cancel request" + "View other resources" actions.

Request sent Pending
Avery Chen has been notified. You'll get an email when they approve or decline. Most requests are answered within a business day.

## Composition rules

- Always show the owner's name — "ask Avery" reads as a real path; "ask the owner" reads as a system error. The owner identity comes from the same authorization data that produced the 403.
- Pre-fill the resource — never make the user re-type the resource name. The link they clicked is the request payload.
- Default role = least-privilege — Viewer is the default; the user can escalate. This is the same posture the role-picker (36a) uses for new members.
- Reason is optional but encouraged — a one-line reason cuts approval lag. Frame the hint around speed, not surveillance.
- Pending state shows the reviewer + ETA — "Avery Chen has been notified · most requests answered within a business day" beats a generic "request sent" toast. The requester can plan around the wait.
- Cancel-request is reversible — let the user pull the request back without contacting the owner. This is a polite-by-default convention.
- Don't auto-grant after timeout — pending should stay pending forever (or until manually canceled). Auto-grant is a security smell.

## See also

- approvals — the owner-side surface (13d). Access requests appear in the approval queue.
- alert-ui — explanation copy on all three surfaces.
- field-ui · select-ui · textarea-ui — request form primitives.
- permissions-role-picker — same role vocabulary as the role select.