> For the complete documentation index, see [llms.txt](https://docs.amply.tools/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amply.tools/concepts/gating-an-action.md).

# Gating an action

Some moments in your app are worth pausing for. **Gating** lets a campaign make the app **wait for something to finish** — a rewarded ad, a quick survey, an upgrade screen — before the user's action goes through, and then continue or back out depending on how it went.

Most campaigns are fire-and-forget: they fire an action and the app keeps moving. A gate is the opposite — it holds the user's next step until the gated action resolves.

## The two halves

* **The app declares the gate-able moments.** A developer marks specific points — "Save", "Export", "Start sync", "Apply filter" — as moments the app is willing to pause at. This is a one-time setup per capability.
* **You compose the campaign.** From the dashboard you attach a campaign to one of those moments — its audience, its cadence, and the action it runs — and it starts gating. Pointing the gate at a different moment the app already exposed is a dashboard change, not a release.

## Use cases

**Watch a rewarded ad to unlock an action.** A free user taps **Export**. The campaign gates it on a rewarded ad: they watch it through → the export runs; they close it early → the export doesn't happen. You monetize a high-intent moment without a hard paywall.

**A one-tap survey before a big step.** Before **Cancel subscription** or **Delete account**, gate on a short reason picker. They pick a reason → the flow continues; they back out → they stay. You capture churn reasons exactly where intent is highest.

**A soft upgrade nudge at a premium moment.** A free user taps a pro-only filter. Gate on an upgrade screen: they upgrade → the filter applies; they dismiss → they fall back to the free version. A contextual upsell at the exact point of desire. (Your app still grants the actual entitlement — the gate shapes the moment, see *When not to gate*.)

**A value-exchange unlock.** "Invite 3 friends to unlock this theme" — gate the unlock on the invite flow completing, so the reward lands the instant the condition is met.

## When not to gate

Gating is for moments where waiting makes sense. Two things should **not** be gated:

* **Permission and consent prompts** — tracking permission, privacy consent, push permission. Don't wire these as gates. Show them as ordinary prompts, record the answer as a user attribute for targeting later, and let the user's action continue regardless. Making a core flow wait on a consent answer risks freezing the user on a prompt.
* **Opportunistic, informational, or navigational actions** — a rate-and-review prompt, a promo screen, an announcement. These should fire and let the app move on.

A simple test: gate it only if "the user deliberately didn't finish this" is a meaningful outcome you'd want to act on. For an ad or a survey, it is. For a consent prompt or a promo, it isn't.

## The safety promise

A gate **never traps the user behind a broken dependency.** If the ad fails to load, the network drops, or the app isn't ready, the user's action goes through anyway. The only time an action is held back is a deliberate "the user chose not to complete it" — for example, closing a rewarded ad before finishing — and only when the campaign is set to treat that as a cancel.

Because of that promise, **a gate is a UX tool, not a lock.** Don't use it as the thing that grants an entitlement or enforces a payment — grant the premium feature in your app or through the store as you normally would, and use the gate to shape the moment around it.

## What you control without a release

Once the app has exposed a gate-able moment, from the dashboard you control: **which campaign gates it, who it targets, how often it fires, what the gated action shows** (for example, a rewarded ad's reward amount or length), and **whether closing it cancels or lets the flow proceed.** Pointing a gate at a different moment the app already exposed needs no release.

## Related

* [Handling deeplinks](/developer-guide/handling-deeplinks.md) — how a developer wires the app's gate-able moments and the action that runs at each
* [Tracking events](/developer-guide/tracking-events.md) — the gate lives at an event the app already tracks
* [Campaign delivery](/concepts/campaign-delivery.md) — how Amply decides which campaign fires at a moment
* [Campaign actions](/concepts/campaign-actions.md) — the fire-and-forget actions a gate sits alongside