# Permission Prompts

Request system permissions like notifications, location, and camera at the right moment in your flows.

Requesting permissions is a natural part of many flows, especially onboarding. Rather than prompting for notifications or location access at a random moment, you can ask at the right point in a flow after the user understands the value.

Permission prompts are not a standalone element. They are a [tap behavior](/docs/dashboard/dashboard-creating-paywalls/paywall-editor-styling-elements#tap-behaviors) called **Request Permission** that you attach to a button or other tappable component. When the user taps it, the system permission dialog appears.

<img alt="A permission prompt configured as a tap behavior" src="__img0" />

Available permissions [#available-permissions]

* **Notification:** Ask for permission to send system notifications.
* **Background Location:** Request location access when the app isn't in use.
* **Location:** Request location access while the app is in use.
* **Read Images:** Access the user's photo library/camera roll.
* **Contacts:** Access the user's contacts.
* **Camera:** Access the device camera.
* **App Tracking Transparency:** Ask to track the user across apps and websites.
* **Microphone:** Access the device microphone.

> **Note**

Permission prompts require iOS SDK 4.12.5+.



If Granted / If Denied [#if-granted--if-denied]

You can add follow-up actions that run depending on the user's response. Use the **If Granted** section to add actions that run when the user allows the permission, and **If Denied** for when they decline. For example, you could navigate to the next page on grant, or show a different page explaining why the permission matters on deny.

Testing permissions in the editor [#testing-permissions-in-the-editor]

You can test permission prompts directly in the editor preview without deploying to a device. When a permission request fires, the editor shows a simulation toast with **Grant** and **Deny** buttons. Clicking either one triggers the corresponding **If Granted** or **If Denied** follow-up actions, so you can verify your entire permission flow works before shipping.

<img src="__img1" />

Testing callbacks in the editor [#testing-callbacks-in-the-editor]

Custom Callback actions can also be tested in the editor. When a callback fires, the editor shows a simulation toast with **Success** and **Failure** buttons. If the callback is configured as **Blocking**, the action chain pauses until you click one. If it's **Non-blocking**, the chain continues immediately and you can click whenever you're ready. This lets you test both paths of your callback logic without writing any SDK code.

<img src="__img2" />

Best practices [#best-practices]

* Request permissions **after** providing value. Users are more likely to accept.
* Explain the benefit clearly (e.g., "Get notified about exclusive deals").
* Consider placing permission prompts after a purchase or key engagement moment.

For more guidance on iOS, view Apple's Human Interface Guidelines [here](https://developer.apple.com/design/human-interface-guidelines/privacy#Requesting-permission).