Permission denied state

Problem Context

• The product has accounts, roles, teams, sharing links, private objects, licenses, compliance policy, or admin-only actions.
• A user is authenticated but cannot view, edit, approve, publish, delete, export, invite, manage, or configure a known object or action.
• The same surface may need different outcomes for wrong account, missing role, read-only access, pending request, declined request, policy block, and no-disclosure security.
• The product must balance recovery and support with privacy, security, and least-privilege rules.

Selection Rules

• Choose permission denied state when the primary cause is missing authorization, role membership, share grant, license entitlement, approval, or organization policy.
• Show the access boundary at the smallest useful scope: whole page, panel, row, file, field, toolbar action, submit step, or admin setting.
• State what the user can still do, such as view read-only content, copy an ID, return to allowed folders, request access, contact owner, or switch account.
• Say which account, workspace, group, or role is currently active when wrong-account recovery is plausible.
• Name the required permission or role in user-facing language, such as Finance viewer, Editor, Publisher, Owner, Maintainer, or Admin.
• Include request state after submission: sent, pending, approved, declined, expired, owner unavailable, or blocked by policy.
• Use a no-disclosure denial when exposing object existence, title, owner, path, or count would leak private information.
• Use error state when the user has access but the operation failed for network, validation, server, timeout, or data reasons.
• Use empty state when there is no safe known object or blocked action to recover, and the main issue is absence of visible items.
• Replace disabled-button-only treatment with explanatory permission text, owner/contact path, and allowed fallback.

Required States

• Whole-object access denied state.
• Action-level denied state for publish, export, delete, invite, approve, manage, or configure actions.
• Read-only state with edit denied but view allowed.
• Request access form with optional reason and requested permission level.
• Request sent or pending state naming the owner or safe recipient.
• Request declined state with safe next steps.
• Approved state that lets users retry or open the resource.
• Wrong-account state with switch-account path.
• Owner unavailable or policy-blocked state.
• No-disclosure state that avoids leaking restricted object details.

Interaction Contract

• The denial is durable until the permission, account, role, policy, or request state changes.
• Request access records the requested role, reason, requester account, target object or action, owner destination, and timestamp when policy allows.
• Switch account returns to the intended resource after authentication when possible.
• Read-only fallback preserves allowed viewing and safe navigation while blocking only restricted actions.
• Owner-assisted paths identify a safe contact, team, admin group, or support route instead of exposing private collaborator lists.
• No-disclosure variants use neutral navigation and support paths without confirming whether the private resource exists.

Implementation Checklist

• Model authorization denial separately from not found, unauthenticated, rate limit, network failure, validation failure, and empty result states.
• Capture denial reason codes that map to safe user copy, requestability, current account, current role, required role, owner visibility, and no-disclosure policy.
• Implement request access flows with submission status, owner routing, approval or decline outcomes, expiry, and duplicate request handling.
• Preserve allowed read-only content and navigation when only a specific action is denied.
• Instrument support-safe diagnostics such as request ID, policy name, account, and timestamp without exposing restricted object data.
• Test wrong account, missing role, revoked share, expired link, pending request, declined request, policy block, owner unavailable, private-object no-disclosure, and screen reader recovery.

Common Generated-UI Mistakes

• Treating authorization denial as a generic retryable error.
• Showing an empty state for a known restricted object without any request or account path.
• Disabling controls without explaining missing access.
• Leaking private object titles, owners, counts, comments, or paths in a denial page.
• Claiming request success before an owner approves access.
• Blocking read-only work when only edit, publish, or admin action is restricted.

Critique Questions

• Can the user tell whether this is missing access, wrong account, policy, or system failure?
• What object or action is safe to name, and what must stay hidden?
• Which current account, role, team, or share grant is being evaluated?
• What role or permission is required for the blocked action?
• Who can grant access, and is that owner path safe to reveal?
• What can the user still do while access is pending or denied?