Permission recovery vs Permission denied state vs Session timeout warning vs Retry

Use permission recovery when a denied user can request a role, switch to an authorized account, contact an owner, escalate a policy block, or resume the original task after access changes.

Permission recovery live example Permission denied state live example Session timeout warning live example Retry live example

Decision dimensions

Dimension	Permission recovery	Permission denied state	Session timeout warning	Retry
UI or UX	UI + UX - Guided workflow for regaining or routing around missing access	UI + UX - Authorization and access-boundary state	UI + UX - Authenticated-session expiry and reauthentication boundary warning	UI + UX - Scoped failed-operation retry control
UI guidance	Show a recovery workspace after denial with the current account, current role, requested role, safe owner or admin destination, request reason, policy limits, status timeline, and original blocked task.	Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed.	Show a visible countdown or clear expiry time before inactivity, absolute session, or reauthentication limits can interrupt work; place the warning near the current task or as a focused dialog when immediate action is required.	Place Retry next to the failed operation, object, or request summary, and name the exact action being retried such as Retry export or Retry payment authorization.
UX guidance	Use permission recovery when users can take a concrete step to regain access, use another identity, request a different role, escalate a policy block, or continue with a safe fallback after an authorization denial.	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.	Use session timeout warning to balance security, privacy, accessibility, and continuity when an authenticated session is about to expire or require reauthentication.	Use retry when a specific operation likely failed for a transient reason and the same operation can be attempted again without losing user context or duplicating side effects.
Good UI	A restricted report recovery panel shows alex@northwind.example lacks Finance viewer access, lets the user request Viewer or Editor with a reason, names Priya as the approver, shows request ACC-2048 as pending, and returns to the report after approval.	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 benefits form shows Your session will end in 2 minutes, says the draft is saved, and offers Stay signed in, Save and sign out, and Sign out.	A report export card says Export CSV failed, keeps the saved filters visible, shows Attempt 1 of 3, and offers Retry export with request EXP-2048.
Bad UI	A blocked report only has Retry, so the user repeats the same denied request.	A denial page says Something went wrong and shows Retry even though the user lacks a required group.	The app logs out after 15 minutes with no countdown and clears a long form.	A generic Try again button appears after every error, including validation and permission failures users cannot fix by repeating the request.
Good UX	A user requests Finance viewer access with a reason, sees the request is pending with Priya, receives approval, opens the report from the same recovery panel, and lands back on the original report.	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 user pauses while gathering documents, sees the remaining time, extends the session once, then saves the draft before policy requires reauthentication.	A user retries the same export after a network timeout, sees the attempt change to sending, and then returns to the recovered download state without re-entering filters.
Bad UX	A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure.	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 user returns from a phone call to find the form gone and a generic access denied page.	The app retries aggressively every second during an outage and makes the service harder to recover.
Best fit	A denied user can request access, switch accounts, ask an admin, join a group, or use a safe fallback to continue.	A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource.	An authenticated session can expire because of inactivity, overall lifetime, assurance policy, or reauthentication requirement.	A load, save, submit, upload, export, sync, payment, or background request failed for a transient or uncertain reason.
Avoid when	The product only needs to state that access is denied and no recovery path exists.	The user is not signed in and the next step is authentication rather than authorization.	There is no authenticated session boundary and the issue is ordinary navigation away.	The error is caused by invalid user input and correction is required.
Required state	Recovery start state with original blocked task and current account.	Whole-object access denied state.	Active session with no warning.	Retryable failed state with affected operation, object, and preserved request context.
Accessibility burden	Move focus to the recovery heading when the workflow opens from a denial.	Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.	Warn users early enough to respond and avoid relying on a rapidly changing countdown as the only information.	Use an action label that names the operation, not only an icon or generic phrase.
Common misuse	Offering Retry for an unchanged authorization denial.	Treating authorization denial as a generic retryable error.	Using a client-only timer that disagrees with the server session.	Offering Retry for every error regardless of whether the user or system state can change.

Permission recovery

UI or UX: UI + UX - Guided workflow for regaining or routing around missing access
UI guidance: Show a recovery workspace after denial with the current account, current role, requested role, safe owner or admin destination, request reason, policy limits, status timeline, and original blocked task.
UX guidance: Use permission recovery when users can take a concrete step to regain access, use another identity, request a different role, escalate a policy block, or continue with a safe fallback after an authorization denial.
Good UI: A restricted report recovery panel shows alex@northwind.example lacks Finance viewer access, lets the user request Viewer or Editor with a reason, names Priya as the approver, shows request ACC-2048 as pending, and returns to the report after approval.
Bad UI: A blocked report only has Retry, so the user repeats the same denied request.
Good UX: A user requests Finance viewer access with a reason, sees the request is pending with Priya, receives approval, opens the report from the same recovery panel, and lands back on the original report.
Bad UX: A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure.
Best fit: A denied user can request access, switch accounts, ask an admin, join a group, or use a safe fallback to continue.
Avoid when: The product only needs to state that access is denied and no recovery path exists.
Required state: Recovery start state with original blocked task and current account.
Accessibility burden: Move focus to the recovery heading when the workflow opens from a denial.
Common misuse: Offering Retry for an unchanged authorization denial.

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.

Session timeout warning

UI or UX: UI + UX - Authenticated-session expiry and reauthentication boundary warning
UI guidance: Show a visible countdown or clear expiry time before inactivity, absolute session, or reauthentication limits can interrupt work; place the warning near the current task or as a focused dialog when immediate action is required.
UX guidance: Use session timeout warning to balance security, privacy, accessibility, and continuity when an authenticated session is about to expire or require reauthentication.
Good UI: A benefits form shows Your session will end in 2 minutes, says the draft is saved, and offers Stay signed in, Save and sign out, and Sign out.
Bad UI: The app logs out after 15 minutes with no countdown and clears a long form.
Good UX: A user pauses while gathering documents, sees the remaining time, extends the session once, then saves the draft before policy requires reauthentication.
Bad UX: A user returns from a phone call to find the form gone and a generic access denied page.
Best fit: An authenticated session can expire because of inactivity, overall lifetime, assurance policy, or reauthentication requirement.
Avoid when: There is no authenticated session boundary and the issue is ordinary navigation away.
Required state: Active session with no warning.
Accessibility burden: Warn users early enough to respond and avoid relying on a rapidly changing countdown as the only information.
Common misuse: Using a client-only timer that disagrees with the server session.

Retry

UI or UX: UI + UX - Scoped failed-operation retry control
UI guidance: Place Retry next to the failed operation, object, or request summary, and name the exact action being retried such as Retry export or Retry payment authorization.
UX guidance: Use retry when a specific operation likely failed for a transient reason and the same operation can be attempted again without losing user context or duplicating side effects.
Good UI: A report export card says Export CSV failed, keeps the saved filters visible, shows Attempt 1 of 3, and offers Retry export with request EXP-2048.
Bad UI: A generic Try again button appears after every error, including validation and permission failures users cannot fix by repeating the request.
Good UX: A user retries the same export after a network timeout, sees the attempt change to sending, and then returns to the recovered download state without re-entering filters.
Bad UX: The app retries aggressively every second during an outage and makes the service harder to recover.
Best fit: A load, save, submit, upload, export, sync, payment, or background request failed for a transient or uncertain reason.
Avoid when: The error is caused by invalid user input and correction is required.
Required state: Retryable failed state with affected operation, object, and preserved request context.
Accessibility burden: Use an action label that names the operation, not only an icon or generic phrase.
Common misuse: Offering Retry for every error regardless of whether the user or system state can change.

Decision rules

Use permission recovery when a denied user can request a role, switch to an authorized account, contact an owner, escalate a policy block, or resume the original task after access changes.
Use permission denied state when the interface mainly needs to explain that the current account lacks the role, share, license, policy exception, or approval required for an object or action.
Use session timeout warning when authentication is expiring or expired; do not send users into access request flows when reauthentication is the recovery.
Use retry when the same authorized operation may succeed after a transient failure; do not use retry for unchanged authorization denials.
Permission recovery must track request ID, requested role, reason, owner or admin destination, pending status, approved or declined outcome, and return path to the blocked task.
Permission denied state may include Request access, but it does not replace the full request lifecycle when owner decisions, duplicate prevention, and resume behavior matter.
Session timeout warning preserves in-progress work and identity continuity; permission recovery preserves task intent while the authorization grant changes.
Retry can appear after approval or role refresh, but only because the permission state changed, not because the original denial should be repeated blindly.
Do not promise access when the request is only sent, pending, policy-blocked, or declined.
Do not expose restricted object titles, owner names, paths, or notification text in permission recovery when no-disclosure policy applies.

Inspect live examples

Permission recovery Permission denied state Session timeout warning Retry

Failure modes

A denied user clicks Retry repeatedly because the UI never offers request access, switch account, or owner escalation.
A permission denied message sends a request but loses pending status after reload, producing duplicate owner notifications.
A session timeout is treated as missing permission, so users request access instead of reauthenticating and preserving work.
A retry button appears after a declined access request even though no authorization state has changed.
A request says access granted before an owner or policy engine approves it.
A recovery notification leaks a restricted file title to an account that should not know the file exists.