Permission request

Problem Context

• The permission boundary is controlled by the operating system or browser rather than only the product's own account settings.
• The resource can expose private user data, device sensors, local files, camera, microphone, notifications, location, contacts, Bluetooth devices, clipboard contents, storage access, payment handlers, or other powerful platform features.
• The product may see granted, denied, prompt-ready, previously denied, permanently denied, limited, approximate, while-in-use, one-time, revoked, blocked-by-policy, or unavailable states.
• The user may need a manual fallback such as upload file, enter address, paste code, type contact, use chat-only mode, open settings, or continue without the optional feature.

Selection Rules

• Choose permission request when the user is authorizing an OS, browser, or device resource such as camera, microphone, location, photos, contacts, notifications, clipboard, Bluetooth, motion sensors, storage access, or another powerful feature.
• Ask in context when the user starts the feature that requires the resource rather than during cold start, account creation, or unrelated navigation.
• Explain why the resource is needed, what action triggered the request, what the user can do without granting it, and whether the permission is one-time, while-in-use, limited, approximate, or persistent.
• Use consent prompt when the decision is active opt-in to optional data use such as marketing, research, personalization, partner sharing, AI training, or sensitive-data processing.
• Use permission sharing when a user or admin grants durable access to another person, group, link, service account, key, or role.
• Use permission recovery when a denied user requests access from an owner or admin after an account authorization boundary.
• Use permission denied state when the product is explaining a role, policy, license, or share boundary after authorization fails.
• Use notification preferences when the user already has or does not need OS notification access and is choosing message channels, topics, frequency, quiet hours, digest behavior, or subscriptions.
• Use privacy settings when the task is long-term account-level privacy controls rather than a just-in-time platform permission prompt.
• Do not use a custom pre-prompt to pressure, mislabel, or repeatedly nag after the user has declined the system prompt.

Required States

• Contextual request state tied to the user action that needs the resource.
• Feature-triggered ask state that names the resource, task, benefit, and optional fallback.
• System prompt ready state immediately before invoking the browser or OS permission prompt.
• Grant permission state with enabled feature, saved status, and next step.
• Deny permission state with respectful refusal copy and no unrelated blocking.
• Denied fallback state with manual address entry, file upload, chat-only mode, or another route that does not need the permission.
• Ask again later state when the user dismisses the explanation before the system prompt.
• Previously denied state that explains why the system prompt may not appear again.
• Permanently denied or settings required state with a stable settings route.
• Limited access state for photo library selection, approximate location, or partial resource grant.
• While-in-use and one-time permission states with clear lifetime expectations.
• Permission revoked state detected when the user changes OS or browser settings.
• Permission status check state for granted, denied, prompt, blocked, unavailable, or policy-limited outcomes.
• Manual fallback state that lets the user complete eligible work without the resource.
• Mobile compact state where resource name, reason, choices, and fallback stay visible.

Interaction Contract

• The product evaluates whether permission is truly needed before declaring or requesting the platform permission.
• The pre-prompt appears only after a feature-triggering action and can be canceled without accepting the system prompt.
• The system prompt is invoked from the feature action or explicit continue action, not from passive page load or hidden timers.
• The requested permission matches the visible feature; a camera action must not trigger contacts, precise location, or notifications without explanation.
• Granting permission enables only the named feature and updates visible status before continuing.
• Denying permission leaves unrelated navigation, account access, and eligible non-resource work available.
• Previously denied, permanently denied, revoked, blocked, and limited states show a settings route or manual fallback instead of repeating a failing prompt.
• The interface updates when permission status changes and records telemetry without collecting resource data before permission exists.

Implementation Checklist

• Inventory every requested permission, the feature that needs it, the user action that triggers it, and whether a lower-permission alternative exists.
• Minimize permission requests and avoid declaring resources that can be handled with pickers, file uploads, manual entry, transient activation, or feature-specific APIs.
• Write pre-prompt copy that names the resource, task, benefit, choice, fallback, and settings path in the same words used by the feature.
• Implement status checks for granted, denied, prompt, limited, one-time, while-in-use, revoked, unavailable, and blocked-by-policy outcomes where the platform exposes them.
• Provide denial fallbacks such as manual address entry, upload file, choose from limited library, continue without notifications, use chat, or open settings.
• Test first ask, grant, deny, dismiss, previously denied, permanently denied, limited photo access, approximate location, revoked permission, mobile layout, keyboard order, and screen-reader labels.

Common Generated-UI Mistakes

• Asking for multiple resources at launch before the user has attempted the relevant feature.
• Using vague copy such as improve your experience instead of naming the resource and task.
• Blocking an entire product after denial even though only one optional feature needed the permission.
• Looping the same system prompt or custom prompt after the user declines.
• Pretending permission is required when a manual fallback or platform picker would work.
• Providing no settings route after the platform stops showing the prompt.
• Requesting a different permission than the visible feature implies.

Critique Questions

• What specific user action makes this permission necessary now?
• Can the task be completed with less access, a picker, limited library, approximate location, one-time access, or manual entry?
• Does the prompt name the exact resource and feature benefit before the system dialog appears?
• What happens after grant, denial, dismissal, limited access, revocation, or settings-required outcomes?
• Can users continue unrelated work when they decline?
• Is the settings route clear when the platform will not show the prompt again?
• Does the requested permission exactly match the resource described in the UI?