UX Patterns Guide
UI + UX Feedback, Status, And System State standard

Permission denied state

Present an explicit permission denied state that states the safe-to-reveal boundary, current identity, required access, available fallback, request or owner path, request status, and policy limits without exposing information the user is not allowed to know.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource.
  • A wrong account or missing team membership is a likely cause.
  • An access request, owner approval, switch-account flow, or read-only fallback can help the user recover.
  • The product needs to communicate least-privilege and policy boundaries without making the state look like a system outage.

Avoid when

  • The user is not signed in and the next step is authentication rather than authorization.
  • The resource truly does not exist or existence must be hidden behind a neutral not-found response.
  • The operation failed for network, server, validation, data, or timeout reasons after permission was granted.
  • The user has no content yet and there is no specific blocked object or action to recover.
  • Revealing request, owner, object, or policy details would violate privacy or security policy.

Problem it prevents

Users cannot recover from access boundaries when a product hides the cause, confuses authorization with system failure, leaks sensitive resource details, or gives no owner-assisted path.

Pattern anatomy

What a strong implementation has to make clear

User need

The product has accounts, roles, teams, sharing links, private objects, licenses, compliance policy, or admin-only actions.

Pattern promise

Present an explicit permission denied state that states the safe-to-reveal boundary, current identity, required access, available fallback, request or owner path, request status, and policy limits without exposing information the user is not allowed to know.

Required state

Whole-object access denied state.

Recovery path

Users keep retrying a request that will always fail until access changes.

Access contract

Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A report page says Quarterly revenue report requires Finance viewer access, shows the current account, names the report owner, and offers Request access and Switch account.
  • A viewer can read a document but the Publish action says Editor access is required and links to the owner rather than disabling the button silently.
  • A user opens a restricted report, sees which account is signed in, requests viewer access with a reason, then sees that the request is pending with the owner.
  • A collaborator with viewer access keeps reading a file while the edit action explains that editor access must be requested from the owner.
Weak implementation

Vague, hidden, hard to recover from

  • A denial page says Something went wrong and shows Retry even though the user lacks a required group.
  • A confidential case page leaks the case title to a user who should not know it exists.
  • The app returns a blank screen for a restricted file, so the user cannot tell whether the file is gone, private, or opened with the wrong account.
  • A request access action submits and immediately says success even though no owner decision exists.
UI guidance
  • Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed.
  • Use a no-disclosure variant when policy must hide existence, title, path, owner, count, or collaborator details from the current account.
UX guidance
  • Use permission denied state when the system knows the user is authenticated but their role, group, share, license, policy, or approval status blocks a specific object or action.
  • Help users self-correct through request access, switch account, read-only fallback, contact owner, return to allowed work, or review request status instead of sending them into retry loops.
Implementation contract

What the implementation must handle

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.

Interaction

  • 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.

Accessibility

  • Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.
  • Move focus to the permission message when it replaces page content or blocks a workflow.
  • Associate action-level permission messages with the affected control using visible text and accessible descriptions.
  • Announce request sent, pending, approved, and declined changes through a polite status region.

Review

  • 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?
Interactive lab

Inspect the states before you copy the pattern

Recover from an access boundary

Switch a workspace report between denied page, read-only, action denied, request access, pending request, denied request, approved access, and switch-account states; compare with blank page, retry loop, hidden owner, leaking title, disabled-only, and false success misuse.

Permission denied state
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Whole-object access denied state.

Keyboard / Access

Focus lands on the access-denied heading or first safe recovery action when the state opens.

Avoid Generating

Treating authorization denial as a generic retryable error.
Evidence trail

Source-backed claims behind this guidance

Microsoft SharePoint access requests

Microsoft Support - checked

SharePoint documents access requests, owner routing, approve or decline outcomes, permission-level assignment, and request history.

Google Drive file access requests

Google Docs Editors Help - checked

Google Drive documents You need access, request access, owner notification, approved or denied outcomes, pending cases, wrong-account recovery, and policy limits.

Full agent/debug reference

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?
Accessibility
  • Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.
  • Move focus to the permission message when it replaces page content or blocks a workflow.
  • Associate action-level permission messages with the affected control using visible text and accessible descriptions.
  • Announce request sent, pending, approved, and declined changes through a polite status region.
  • Keep request, switch account, contact owner, read-only view, and safe navigation controls reachable by keyboard.
  • For no-disclosure states, make the neutral page understandable without exposing restricted object data in accessible names.
Keyboard Behavior
  • Focus lands on the access-denied heading or first safe recovery action when the state opens.
  • Tab order moves from explanation to request access, switch account, read-only view, owner contact, and safe exit actions.
  • Request access forms keep labels, reason fields, permission selectors, submit, cancel, and status messages in logical order.
  • After submitting a request, focus moves to the pending status and the next safe action.
  • If access is approved after refresh, focus returns to the formerly blocked object or action.
  • Disabled restricted actions are not the only path; an enabled control or message explains the missing permission.
Variants
  • Whole-page access denied
  • Action-level access denied
  • Read-only with edit denied
  • Request access
  • Pending access request
  • Access declined
  • Access approved retry
  • Wrong account
  • Owner unavailable
  • Organization policy block
  • No-disclosure denial

Verification

Last verified: