> ## Documentation Index
> Fetch the complete documentation index at: https://docs.insito.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Triggers

> How you wire the moments that show a survey — configured per survey in the builder's Trigger tab.

Triggers are configured **per survey**, in the survey builder's **Trigger** tab
(not in a separate project-wide screen). Open a survey from
[admin.insito.app](https://admin.insito.app) → your project → **Surveys**, then
switch to the **Trigger** tab.

## Trigger conditions

The Trigger tab lets you enable one or more condition cards, combined with
**OR** logic (the survey fires when any enabled condition qualifies):

* **App event** — one or more event keys your app fires with
  `MicroSurvey.trigger("checkout_completed")`.
* **Screen visit** — one or more screens, optionally with an "after N visits"
  threshold.
* **App open** — after a minimum number of app starts (cold launches by
  default; can include foreground resumes).
* **Set delay** — wait N seconds after a condition qualifies before showing.

The event-key and screen-name fields are searchable selects backed by the
[Events and Screens registry](/dashboard/variables). Only **approved** variables
appear in the picker; you can also type a new key, which registers as a manual
variable.

## Frequency and throttling

Below the conditions, the Trigger tab controls how often the survey can appear:

* **Minimum days between shows** (`throttle_days`, default **7**) — the
  project-wide throttle window. See [throttling](/concepts/throttling).
* **Max shows per user** — a hard cap on how many times this survey is ever
  shown to one user, counted from the `impressions` table.

## Confirming a trigger is wired

After shipping a version that fires a new key, watch for it to appear in the
**Auto-discovered** list under **Settings → \[your app] → Events** (or
**Screens**). If nothing shows up after some production traffic, check:

* The key in the dashboard matches the string in your app **exactly** (keys are
  case-sensitive; there's no server-side normalisation).
* `MicroSurvey.identify()` ran before the trigger.
* The SDK is initialised (turn on `debug: true` in development).

<Note>
  A survey only shows if throttling passes, a condition matches, the survey's
  response limit isn't reached, audience filters pass, and the per-user show cap
  isn't hit — evaluated in that order. See
  [Triggers (concepts)](/concepts/triggers) for the full evaluation flow.
</Note>

## Targeting by audience

A trigger decides *when* a survey is evaluated; the **Audience** tab decides
*who* qualifies. Audience filters run against two kinds of properties:

* **Device properties** — auto-captured by the SDK on every `identify()`
  (`platform`, `app_version`, `locale`, `timezone`, `osVersion`, `sessionCount`,
  `daysSinceInstall`, `environment`). No setup required.
* **User properties** — custom, business-level attributes you send via
  [`identify({ properties })`](/sdk/react-native/api-reference#microsurvey-identify-args),
  discovered into the [User Properties registry](/dashboard/user-properties).

The property picker groups these two sources, and the available operators adapt
to each property's type (text, number, or boolean). For example: only show an
upsell when `plan equals "free"` **and** `daysSinceInstall ≥ 7`.

## Screen triggers

If you use [screen tracking](/sdk/react-native/screen-tracking), the SDK reports
visited screens (and fires `screen_viewed:<pathname>`). Reported screens show up
under **Settings → \[your app] → Screens** and in the project's
[Screen map](/dashboard/variables) view, where you approve the ones you want to
use as **Screen visit** trigger conditions.