Permission recovery

Problem Context

• The product has already determined that authorization, role membership, sharing, policy, license, or owner approval blocks a known task.
• The user has a viable recovery path such as request access, switch account, choose a lower-risk fallback, contact an owner, ask an admin, join a group, or escalate a policy exception.
• The request may have asynchronous states: sent, pending, duplicate, approved, declined, expired, owner unavailable, or policy blocked.
• The product must preserve least-privilege and no-disclosure rules while giving users enough state to recover without support guesswork.

Selection Rules

• Choose permission recovery when the interface needs to guide users through request, approval, switch-account, policy, fallback, or retry-after-grant steps after a permission denial.
• Use permission denied state for the durable blocked access message itself; permission recovery is the workflow that follows when recovery actions are possible.
• Use session timeout warning when authentication expired or is about to expire; use permission recovery when the user is authenticated but lacks authorization.
• Use retry only after a permission or role change has happened; retrying the same denied request is not recovery.
• Use error state when an operation failed despite adequate authorization, not when the required role or share grant is missing.
• Name the original blocked task and return destination when policy allows, so successful recovery resumes the user's intent.
• Collect only access-relevant information such as requested role, reason, duration, account, workspace, object, owner, and policy exception.
• Show duplicate request, pending request, approved, declined, expired, owner unavailable, and policy-blocked outcomes distinctly.
• Offer wrong-account switching before owner requests when another signed-in account already has access.
• Do not promise access before an authorized owner, admin, policy engine, or entitlement system grants it.

Required States

• Recovery start state with original blocked task and current account.
• Requested role selection state.
• Reason or justification entry state.
• Owner or admin routing state.
• Request sent state with request ID and destination.
• Pending request state that prevents duplicates.
• Approved state with retry or reopen original task.
• Declined state with safe fallback or escalation.
• Wrong-account switch state with return path.
• Policy-blocked or owner-unavailable state with support-safe escalation.

Interaction Contract

• The recovery workflow opens from a known permission denial and keeps the original object or action attached when safe to reveal.
• Submitting a request records requester account, requested role, reason, target, owner or admin destination, timestamp, and request ID.
• A duplicate request reopens the existing pending state instead of sending another owner notification.
• Switch account returns to the intended object or action after authentication when possible.
• Approval changes the available actions and lets users retry, reopen, or resume the original task.
• Decline, expiry, policy block, and owner-unavailable states explain what will not change through retry and offer safe alternatives.
• No-disclosure policies suppress restricted object metadata while still allowing neutral account, support, or policy recovery.
• Notification or email outcomes deep-link back to the recovery state instead of losing the request context.

Implementation Checklist

• Model permission recovery separately from unauthenticated, not found, operation failure, validation failure, and empty-content states.
• Store recovery state with denied action, target object, requestability, current account, current role, requested role, owner visibility, policy limit, request ID, status, and return URL.
• Implement role selection, reason entry, request submission, duplicate-request detection, pending status, cancel or update request, approval, decline, expiry, and escalation flows.
• Detect wrong-account cases and preserve the intended resource through account switching.
• Route owner-unavailable and policy-blocked states to admins, support, or allowed fallback instead of resending impossible requests.
• Keep safe fallback tasks such as read-only view, copy ID, open allowed dashboard, or contact manager available while recovery is pending.
• Test owner approval, owner decline, duplicate request, reload during pending, notification return, wrong account, policy block, no-disclosure, request expiration, keyboard access, and screen reader status announcements.

Common Generated-UI Mistakes

• Offering Retry for an unchanged authorization denial.
• Treating request submission as access approval.
• Hiding pending request status and sending duplicate owner notifications.
• Letting users request a role that the target owner cannot grant.
• Losing the original blocked task after approval.
• Exposing restricted object details in request history or notifications.
• Blocking safe read-only or fallback work while access is pending.

Critique Questions

• What exact role, share grant, license, or policy change would recover the task?
• Who can approve it, and is that destination safe to reveal?
• Can the user switch to an account that already has access before requesting new access?
• What prevents duplicate requests while a decision is pending?
• How does the user resume the original blocked task after approval?
• What happens when access is declined, expired, owner-unavailable, or policy-blocked?