Permission denied state vs Error state vs Empty state vs Disabled button with no explanation

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.

Permission denied state live example Error state live example Empty state live example Disabled button with no explanation live example

Decision dimensions

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.	Render a resolved no-data region with a specific heading, cause text, one primary action when available, optional secondary path, and restrained illustration or icon support.	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.	Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.	Help users distinguish legitimate absence from loading, no-results, error, permission, and setup conditions before offering a next step.	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.	Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.	No projects yet heading, short explanation, Create project primary button, Import CSV secondary button, and visible workspace context.	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.	A blank white table body with no text, object name, or action.	Create workspace is greyed out with no nearby text, checklist, or request-access route.
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	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.	Clearing work after save failure.	The same empty message appears for loading, search no-results, permission denial, and service failure.	Users change random fields because the unavailable action never states the missing condition.
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.	The product area can legitimately contain no user data.	Use this anti-pattern entry to audit disabled submit, continue, create, save, delete, publish, invite, export, payment, and setup actions.
Avoid when	The user is not signed in and the next step is authentication rather than authorization.	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	Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.	Use appropriate alert or status semantics for newly appearing critical errors.	Keep the message in normal reading order near the empty region it explains.	Do not make the only explanation unreachable because the control is disabled, skipped by focus, or hidden behind hover.
Common misuse	Treating authorization denial as a generic retryable error.	Using a transient toast for critical errors.	Showing a blank page with no explanation.	Greying out Continue until every field is valid without showing the missing or invalid answers.

Permission denied state

UI or UX: UI + UX - Authorization and access-boundary state
UI guidance: Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed.
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.
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.
Bad UI: A denial page says Something went wrong and shows Retry even though the user lacks a required group.
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.
Bad UX: 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.
Best fit: A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource.
Avoid when: The user is not signed in and the next step is authentication rather than authorization.
Required state: Whole-object access denied state.
Accessibility burden: Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.
Common misuse: Treating authorization denial as a generic retryable error.

Error state

UI or UX: UI + UX - Recoverable failure surface
UI guidance: Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance: Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI: Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI: Tiny transient toast for a blocking failure.
Good UX: User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX: Clearing work after save failure.
Best fit: A system or task failure blocks expected content or action.
Avoid when: Nothing exists yet and the state is expected.
Required state: Normal expected state before failure.
Accessibility burden: Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse: Using a transient toast for critical errors.

Empty state

UI or UX: UI + UX - Resolved no-data content surface
UI guidance: Render a resolved no-data region with a specific heading, cause text, one primary action when available, optional secondary path, and restrained illustration or icon support.
UX guidance: Help users distinguish legitimate absence from loading, no-results, error, permission, and setup conditions before offering a next step.
Good UI: No projects yet heading, short explanation, Create project primary button, Import CSV secondary button, and visible workspace context.
Bad UI: A blank white table body with no text, object name, or action.
Good UX: Users can create the first project, import existing work, or request access depending on the actual cause.
Bad UX: The same empty message appears for loading, search no-results, permission denial, and service failure.
Best fit: The product area can legitimately contain no user data.
Avoid when: The absence was caused by filters or search.
Required state: First-use empty state before any objects exist.
Accessibility burden: Keep the message in normal reading order near the empty region it explains.
Common misuse: Showing a blank page with no explanation.

Disabled button with no explanation

UI or UX: UI + UX - Blocked action anti-pattern
UI guidance: 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: Help users understand whether the block is missing input, invalid data, permission, quota, dependency, safety policy, or temporary processing.
Good UI: Create workspace is paired with visible requirements: enter a workspace name, accept billing terms, and request owner access.
Bad UI: Create workspace is greyed out with no nearby text, checklist, or request-access route.
Good UX: Users can satisfy requirements one by one and see the action become available, or submit and receive actionable validation.
Bad UX: Users change random fields because the unavailable action never states the missing condition.
Best fit: Use this anti-pattern entry to audit disabled submit, continue, create, save, delete, publish, invite, export, payment, and setup actions.
Avoid when: The action remains available and returns actionable validation after activation.
Required state: Unavailable action state with visible reason and affected requirement.
Accessibility burden: Do not make the only explanation unreachable because the control is disabled, skipped by focus, or hidden behind hover.
Common misuse: Greying out Continue until every field is valid without showing the missing or invalid answers.

Decision rules

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 error state when a request, load, save, payment, sync, or background job failed even though the user appears authorized to attempt the operation.
Choose empty state when the collection or workspace has no content yet, or when a permission-limited collection can safely say no visible items without naming a blocked object.
Treat disabled-button-no-explanation as an anti-pattern when a blocked action only appears as an inactive control; replace it with inline, page-level, or modal access guidance that says why the action is unavailable and what recovery exists.
Name the blocked object or action only when policy allows the user to know it exists; otherwise use a no-disclosure access message that avoids leaking titles, owners, counts, or paths.
State the current account, team, role, or permission level when that helps users self-correct, such as switching accounts or requesting editor access instead of viewer access.
Provide a concrete recovery path such as request access, contact owner, switch account, join team, use read-only view, return to allowed area, or open an access request status.
Show request outcomes separately from the denial: sent, pending, approved, declined, expired, owner unavailable, or blocked by organization policy.

Inspect live examples

Permission denied state Error state Empty state Disabled button with no explanation

Failure modes

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.
A known document is presented as an empty folder, so the user cannot request access or check whether they are signed into the wrong account.
A publish button is disabled without naming the missing Admin role or offering an owner-assisted path.
A denial page leaks the confidential document title to a user who should not know that the document exists.
A request access form submits but never shows whether the owner received, approved, declined, or left the request pending.
A user with viewer access loses the safe read-only view when only the edit action should be blocked.