Triggers

Triggers are the heart of Nudge. One trigger is one rule: when a contact matches these conditions, take these actions. Chains of small triggers replace the do-everything flowchart.

​

What starts a trigger

Three different things can set a trigger off, and you pick which when you create it:

• Lead state, the default. The contact’s fields changed and now match your conditions. This is the classic “possibility became Quote sent” rule.
• Call outcome. An AI call finished. The trigger can read whether it was answered, which agent ran it, and what the call collected, so “no answer, try WhatsApp tomorrow” is one rule.
• Reply received. A contact wrote back. You can scope it to specific mailboxes, which is how “anyone who replies to info@ gets tagged for review” works.

Only lead-state triggers decide which contacts get pulled from HubSpot. Enabling one is what turns intake on for its audience. The other two react to contacts you already have.

​

Anatomy of a trigger

• Owners: which reps’ contacts this trigger covers. A trigger can serve the whole team or one rep.
• Conditions: field-based rules, grouped with AND/OR. “Possibility is Quote sent” is the classic, but any registry field works: postcode starts with 6, budget above X, homeowner is Yes.
• Message actions: one or more sends, each with its own channel (WhatsApp, email or call), delay, and send window. A single trigger can call immediately AND queue a WhatsApp for two days later.
• CRM writes: what to set when the trigger fires, when its last message has been sent, or when a call ends. This is how chains form: the call action’s “on failure set possibility to No answer” is what arms the no-answer follow-up trigger.

​

Send windows

Each WhatsApp action picks when it is allowed to fire: Business hours holds until the owner’s working hours, Anytime sends immediately, Off-hours only deliberately waits for the evening. Calls always clamp to the calling agent’s hours; emails send any time.

​

Delayed messages are re-checked before they go out

A message queued for tomorrow is not sent blindly tomorrow. Just before it goes out, Nudge refreshes that contact from your CRM and checks the trigger’s conditions again. If the contact no longer matches, the message is cancelled instead of sent. This is automatic and always on — it is what stops a three-day drip from messaging someone who was reached on day one. Sometimes the rule that lets a contact in is not the rule that should keep the send alive. Re-check before sending lets you write a separate, narrower check for that moment. The case it exists for: a callback trigger enters on “call-back time is set or status is Call Back”, because either signal means the contact asked to be called. Two hours later only the status still means anything — the call-back time is a record of what was said on the call and never goes away. Without a separate check, moving that contact’s status by hand wouldn’t stop the call. With Re-check before sending set to just “status is Call Back”, it does. Turn it on and it starts as a copy of your conditions, which you then cut down. Turn it off and you are back to re-checking the conditions themselves.

​

Seeing what is queued

Activity → Queued lists everything scheduled and not yet sent, soonest first, across every channel. Each row shows when it fires, who it goes to, and which trigger queued it. Hover a row for Cancel to stop that one send. The rest of Activity is a record of what already happened, so a message waiting on a two-day delay never appeared there. Queued is the other half: what is about to happen. The Dashboard’s Queue count links straight to it.

​

When CRM writes happen

A trigger’s property writes normally land the moment it fires. On a trigger that sends a sequence, that is often too early — “we tried three times and got nothing” isn’t true until the third message has actually gone. Set Apply to After the last message is sent and the writes wait for the final message in the trigger to go out. If the sequence stops early, they never happen at all: the contact replied, the contact stopped matching, the send failed. That is the point of the setting. Use When the trigger fires for anything that marks the start of something, like flagging a contact as awaiting a callback.

​

Enabling a trigger

This is the single most important choice in the editor, and the one that surprises people. New triggers start disabled. When you switch one on, you decide what happens to the contacts who already match:

• Only new matches (the default). The trigger fires from here forward. Everyone currently sitting in that state is skipped, on purpose.
• Include current matches. The trigger fires for the existing backlog too, immediately.

Pick the default unless you specifically want the backlog worked. A rule like “possibility is New” can match thousands of dormant contacts, and Include current matches will message all of them. Before you commit, Check matches counts the current draft against your contacts and tells you how many it would hit. Use it every time. It costs a click and it has saved more than one accidental blast.

​

Pausing on reply

By default a trigger’s queued messages are cancelled when the contact replies, so nobody gets automated at while a rep is mid-conversation. Each trigger has its own toggle for this. Turning it off is right in one specific case: the contact asked for the thing. A callback they booked should still happen even though they just wrote to you.

​

Once per contact

A trigger fires once per contact, ever. A contact bouncing back into the same state does not get the same message twice. Editing a trigger resets this, so your corrected version reaches the audience again; still-queued sends from the old version are cancelled at the same time.

​

Categories

Trigger categories are yours to define, and each becomes its own sidebar tab. The demo ships with Lead qualification and Newsletter; add categories like Reactivation or Onboarding in Workspace setup. New triggers start disabled so you can review them before they touch live contacts.