A trigger is the block that decides when an automation starts. It's the first piece of every flow and, in practice, the most consequential decision: everything else — which emails go out, with what waits, with what branches — can be changed at any time, but a badly chosen trigger means the flow simply never runs, without raising an error anywhere. This document is the reference for arrobaMail's five triggers and its behavior conditions. The general mechanics of a flow are in automations.
The five triggers
In the automation editor palette, the Triggers category holds five blocks:
| Trigger | Fires when… | Requires | Step-by-step guide |
|---|---|---|---|
| Subscription | a contact confirms their sign-up to a list | a list and a subscription form | welcome from a form |
| Unsubscription | a contact opts out of a list | a list | — |
| Email open | a contact opens a sent campaign | a campaign already sent | opens and clicks |
| Email click | a contact clicks in a campaign (optionally, on a specific link) | a campaign already sent | opens and clicks |
| Custom event | your system records an event through the API | the contact already on the list + an HTTP call | firing through the API |
Three of them are the ones that start conversations: Subscription, Custom event and Open/Click. Unsubscription is for the opposite — closing well: a goodbye message, an exit survey, or flagging the contact in your own system.
Subscription
Fires when someone confirms their sign-up to the list you choose.
That confirmation nuance is the source of nearly every "it doesn't fire" question. arrobaMail protects lists with double opt-in: the person submits the form, receives a confirmation email, and only on confirming do they enter the flow. Between the form submission and the start there is, therefore, a step that depends on the person.
Two practical consequences:
- Manually added contacts don't fire it. They stay active on the list, but there was no real subscription, so the trigger doesn't see them.
- Neither do sign-ups made by your system. If your backend adds contacts through the API, that "visible" opt-in never happens. The custom event exists for that case.
Unsubscription
Fires when a contact opts out of a list. It's the least used trigger and the most underrated: an opt-out is valuable information, and a short flow — a message thanking them for their time, or offering a lower frequency instead of leaving altogether — wins back more people than you'd expect.
Use it for internal tasks too: notifying your CRM, flagging the contact, or firing a one-question exit survey.
Email open and Email click
These fire when a contact opens or clicks in a campaign. When configuring them you pick which campaign: behavior is measured against one specific send, not against "any email".
The click trigger also lets you pick which link. Leave the link selection empty and it fires on any of them; pick one and it fires only on that. That enables very fine-grained flows: in a campaign with "see plans", "read the case study" and "talk to sales", each click reveals a different intent and can start a different conversation.
The two signals are not worth the same:
- An open is a weak signal. It says "the subject line caught my eye". On top of that, the privacy protection features in some email clients can preload images and register opens that weren't human.
- A click is a strong signal. The person went all the way to the link: there's intent.
Practical rule: opens for soft logic (tone, message order), clicks for important decisions (sending an offer, notifying sales).
Custom event
This is the most flexible of the five, and the one that turns arrobaMail into something any system can operate. Your application records an event with an HTTP call and the flow starts. In practice it's an inbound webhook-style trigger.
It has two configuration fields:
- Event name — a fixed identifier, no spaces, lowercase (
purchase_confirmed,trial_expired). It works as a contract: it has to match exactly what your system fires. - Value (optional) — a fine-grained filter. With it, one event can drive different flows depending on the value it carries.
The endpoint the dashboard builds is:
GET /v3/api/events/record?eventName=NAME&email=[SUBSCRIBER_EMAIL]&listid=[LIST_ID]
Two rules that prevent most problems:
- The event fires, it doesn't create. The contact has to already exist on the list. Sign-up first, event second.
- Call from your backend, never from the browser. If the trigger fires from the front end, anyone can read the URL — with your
listid— and start flows for arbitrary addresses.
You can also attach temporary fields prefixed with pf_ (pf_order_id, pf_total) that travel with the event and are used inside the email without being stored on the contact.
Behavior conditions
Opens and clicks appear also under Conditions, and there they do something different: they don't start a flow, they branch one that's already running. After an email and a wait, the condition asks "did they open?" or "did they click?" and sends the contact down one branch or the other.
The rule for choosing between trigger and condition is a single question: is the person already inside the flow? If they're not, trigger. If they are, condition.
And one design warning: always place a wait before the condition. Asking "did they click?" ten minutes after the send routes almost everyone down the "no" branch, simply because they haven't read the email yet. One day is the reasonable minimum; two or three is the norm.
Variables available in the flow's emails
Inside an automation's emails you can insert contact and event data. The syntax uses triple braces and a $ sign:
{{{$sus_field}}}— stored subscriber data ({{{$sus_name}}},{{{$sus_email}}}). The field name matches exactly what's stored on the list, capitalization included.{{{$pf_field}}}— temporary fields that arrived with a custom event ({{{$pf_order_id}}}). They aren't stored on the contact: they exist only for that send.
If the data is missing, the variable resolves empty. Set a default value for any field you use in greetings, or you'll be sending a "Hi ,".
Common mistakes and how to spot them
Almost every "the automation doesn't work" falls into this list, in order of frequency:
- The flow is in Draft. It saves, it looks fine, and it processes nobody. This is cause number one.
- The trigger points at a different list than the form or the sign-up. No visible error: simply nobody enters.
- The contact didn't confirm (Subscription trigger) or wasn't on the list (custom event).
- The event name doesn't match character for character what your system fires.
- The condition is evaluated too early, with no wait before it.
The fastest way to diagnose is the automation panel's enrollment count: note it down, trigger the event, and look again. If it didn't move, the signal never arrived; if it moved and no email went out, the problem is further along the flow.
Keep reading
- Automations — how a flow is composed: actions, waits, conditions and logic.
- Subscription forms — where the sign-ups that fire «Subscription» come from.
- Connecting arrobaMail to your systems — the full integration picture, v3 API included.