Create a trigger
A trigger watches an event and sends a payload when its conditions are met. For example, it can wait after an add-to-cart event and cancel when the same profile converts. Follow Launch your first trigger for a complete, paused setup with a controlled webhook destination.
Before you start
Confirm the source event exists in AXO, the destination is configured, and the required identifier belongs to the same visitor profile. An email trigger needs an email identifier and the applicable consent. A page visit alone does not supply an email address.
Decide what starts the trigger, what cancels it, how long to wait, and how the receiving service will confirm the intended action. See the connector guides for destination setup.
Create trigger enables delivery immediately. The dashboard has no save-as-paused option. Content's Review before publishing setting and the website's Pre-launch mode do not stage triggers. To review a paused trigger first, use the developer-assisted API procedure in Launch your first trigger.
Create a trigger in the dashboard
Use this path only when the destination and its downstream actions are ready for delivery.
- Open Triggers and click New Trigger.
- Choose Conversion forwarding (CAPI), Lifecycle email, or Custom / advanced. Conversion forwarding sends events through a conversion API.
- For lifecycle or custom triggers, set Name, Mode, Identifier, and Watch event. For a delayed trigger, choose the Cancel event, Delay (minutes), and Cooldown per profile (hours).
- Choose the Destination integration. Payload renders a template; Ping calls a templated URL; Native builds a supported provider's event. Select the format your receiver expects.
- Review Holdout override, Suppress if converted recently, and any engagement or subscription gates. A holdout intentionally receives no dispatch and supplies a control for measurement.
- Click Create trigger to enable it. Confirm the saved row says LIVE. Use Pause to prevent new candidate selection; evaluation already in flight may finish. Resume enables it again.
The form does not expose a general positive audience-condition builder. For precise watch-event filters, an implementer can set criteria through the API or create_trigger/update_trigger. Cancel if profile is currently in segment is a cancellation rule, not a positive audience selector.
Verify the intended operation
Preview rendered body in the template editor renders sample values without sending them. It checks payload shape. It cannot prove that a real visitor qualifies or that a destination accepts delivery.
Test fire sends a real payload. It asks for an existing profile ID and can dispatch while the trigger or integration is paused. It bypasses the watch event, delay, audience criteria, cancellation, consent, suppression, holdout, cooldown, and normal rate checks. It also uses the payload-template path, so it does not validate a Ping or Native dispatch configuration. Use it only for an explicitly intended direct send to a controlled destination and recipient.
A trigger installed from a lifecycle recipe tests differently: Test fire asks for a test email address, phone number or external ID, shows the exact payload each destination would receive, and sends only after you confirm. It refuses an identifier that belongs to a visitor on your site. See the lifecycle recipe guides.
To verify eligibility, cancellation, and suppression, exercise the normal event-processing path in an isolated test environment. Check both a qualifying profile and one that should be excluded. Test-fire success does not establish those conditions.
Open History to inspect destination results, then check the receiving system. HTTP success means the receiver accepted the request; an email delivery, CRM update, or downstream automation needs its own evidence. Test fires also write History rows, marked TEST. They are left out of lift and are not announced to integration webhooks as trigger.fired, but they count in the trigger’s fired total, so exclude them from customer performance conclusions.
Diagnose, stop, and measure
| What you see | What to check next |
|---|---|
| No History row | Confirm the trigger is enabled and the exact watch event reached AXO with a profile. Check criteria, delay, cancellation, event-processing progress, and expiry. A cancelled candidate can produce no fire row. |
| A skipped row | Read the skip reason. Common reasons include missing identifier, cooldown, recent conversion, consent, current segment state, and holdout. |
| An error row | Check the destination's active state, template, credentials, response code, and receiver logs. Normal completed dispatch errors are not automatically retried by the next evaluator tick. |
| Success but no business action | Check the receiver's event mapping, automation state, suppression, and processing log. A receiver can accept an event without completing its intended action. |
Pause prevents new candidate selection. Evaluation already in flight can still send, and Pause cannot recall a dispatched request or cancel work already running in the receiver. Ask AXO to check in-flight work before declaring the stop verified. Pending candidates remain stored and may become eligible after Resume if they have not expired. Ask AXO to check candidate and event-processing state before resuming after an incident; those reads are not exposed by a self-service queue screen. If stale work remains, keep the trigger paused and follow the expiry and operator-check procedure.
For results, use Trigger performance. Review evidence sufficiency, treatment and control counts, and the outcome being measured. Disabling holdout removes that comparison. Follow Performance and lift before making a lift claim.