Permission recovery is the request, approval, account-switch, and fallback workflow after authorization blocks a task. Permission denied state explains the boundary, session timeout warning handles authentication expiry, and retry repeats a failed operation only when repetition can change the result.
Permission recovery is the request, approval, account-switch, and fallback workflow after authorization blocks a task. Permission denied state explains the boundary, session timeout warning handles authentication expiry, and retry repeats a failed operation only when repetition can change the result.
Practice the judgment: Imagine this situation: A permission denied message sends a request but loses pending status after reload, producing duplicate owner notifications. 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 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. | Help the person reach a clear task outcome. |
| 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 countdown shows time remaining after the server has already expired the session. | Retry creates duplicate records, payments, invitations, exports, or queued jobs. |
| 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 second failure increases the wait before the next attempt and then offers cached export, background notification, or support reference after attempts are exhausted. |
| Bad UX | A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure. | Every workspace control is disabled after one missing permission, including safe navigation and read-only tasks. | 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 user is unauthenticated and the next step is sign-in or session extension. | The operation failed for network, server, validation, data, or timeout reasons after permission was granted. | The user lacks authorization while still signed in. | 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. | Early idle warning with remaining time and current save state. | 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. | Move focus to the permission message when it replaces page content or blocks a workflow. | Warn users early enough to respond and avoid relying on a rapidly changing countdown as the only information. | Expose pending, failed again, cooldown, succeeded, exhausted, and non-retryable outcomes through status text or live regions. |
| 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. |