Choose permission denied state when the current authenticated account lacks the role, group membership, share grant, license, policy exception, or admin approval required to view, edit, publish, export, delete, invite, approve, or manage a resource.
Choose permission denied state when the current authenticated account lacks the role, group membership, share grant, license, policy exception, or admin approval required to view, edit, publish, export, delete, invite, approve, or manage a resource.
Practice the judgment: Imagine this situation: A private report shows a generic server error and sends users into a retry loop even though the server has already returned an authorization denial. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Permission denied state | Error state | Empty state | Disabled button with no explanation |
|---|---|---|---|---|
| UI or UX | UI + UX - Authorization and access-boundary state | UI + UX - Recoverable failure surface | UI + UX - Resolved no-data content surface | UI + UX - Blocked action anti-pattern |
| UI guidance | Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed. | Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions. | Keep surrounding context such as table title, filters, or workspace name visible so users know exactly what is empty. | Replace a lone greyed-out action with visible requirement text, a checklist, permission message, or enabled validation submit that tells users what blocks progress. |
| 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. | Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI. | Move users toward the first useful object or prerequisite, and replace unavailable actions with permission or configuration guidance. | Help users understand whether the block is missing input, invalid data, permission, quota, dependency, safety policy, or temporary processing. |
| Good UI | 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 failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation. | Permission variant explains that projects exist only after an admin grants access and offers Request access instead of Create. | Create workspace is paired with visible requirements: enter a workspace name, accept billing terms, and request owner access. |
| Bad UI | A denial page says Something went wrong and shows Retry even though the user lacks a required group. | Tiny transient toast for a blocking failure. | Oversized decorative art and vague welcome copy that hides the task. | Disabled controls hide the only validation feedback from keyboard and assistive technology users. |
| Good UX | 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. | User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state. | Users can create the first project, import existing work, or request access depending on the actual cause. | Users can satisfy requirements one by one and see the action become available, or submit and receive actionable validation. |
| Bad UX | Every workspace control is disabled after one missing permission, including safe navigation and read-only tasks. | Clearing work after save failure. | A primary Create button is shown to a read-only user and fails after activation. | Disabled controls hide the only validation feedback from keyboard and assistive technology users. |
| Best fit | A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource. | A system or task failure blocks expected content or action. | A next setup, creation, import, sample, or access-request action is available or explainable. | Use this anti-pattern entry to audit disabled submit, continue, create, save, delete, publish, invite, export, payment, and setup actions. |
| Avoid when | The operation failed for network, server, validation, data, or timeout reasons after permission was granted. | Nothing exists yet and the state is expected. | The absence was caused by filters or search. | The action remains available and returns actionable validation after activation. |
| Required state | Whole-object access denied state. | Normal expected state before failure. | First-use empty state before any objects exist. | Unavailable action state with visible reason and affected requirement. |
| Accessibility burden | Move focus to the permission message when it replaces page content or blocks a workflow. | Use appropriate alert or status semantics for newly appearing critical errors. | Keep the message in normal reading order near the empty region it explains. | Keep requirement text in normal reading order and near the unavailable action. |
| Common misuse | Treating authorization denial as a generic retryable error. | Using a transient toast for critical errors. | Using marketing copy instead of a task-specific next step. | Using disabled state to hide permission, quota, account lock, or system dependency problems. |