Triggers and timing

Timing is where automations go wrong. This page covers the trigger types, how delays actually count, what to do about the sequence that fires while another is mid-flight, and when not to send.

Trigger types#

An automation has one trigger. It falls into one of four families.

Joining a list

A contact is added to a list, and that puts them into the automation. This is the trigger behind almost every welcome sequence, and the most predictable one, because the event happens once per contact per list. Its one hazard is the contacts already on the list when you activate. Read the section on existing members in Build a workflow first.

A field changing

A field on the contact takes a new value, and that starts the automation. Useful when your form or your own systems record something meaningful, for example a plan name, a lifecycle stage, or the source that brought the contact in.

The hazard is repetition. If the same field can be written more than once, the same contact can qualify more than once, and anything that writes to your contacts on a schedule can rewrite the same value repeatedly. Guard against it by setting a separate field the first time the automation runs and checking that field at the top.

A date arriving

A date stored on the contact comes around, and the automation runs. Renewal dates, trial end dates, anniversaries and birthdays all work this way.

Two things to watch. The offset: an email about a renewal is useful a week before the date and useless the day after. And the empty case: contacts with no value in that date field never qualify, which is correct but easy to mistake for a broken automation.

Activity

The contact did something with an earlier email, typically opening it or clicking a link, and that starts a follow-up.

Click is the reliable signal. Open is not. Open tracking depends on the recipient's mail client loading a tracking image, and many clients block that image or prefetch it automatically, so false negatives and false positives are both common. Trigger on clicks where you can, and where you use opens, use them to soften a message rather than to withhold one.

How delays actually count#

A delay counts from the moment the contact reaches the delay step. It does not count from when they entered the automation.

That distinction causes most timing surprises. Three email steps with a two-day delay before the second and a three-day delay before the third puts the third email on day five, not day three. Write the running total beside each step while you build:

Step 1  email          day 0
Step 2  delay 2 days
Step 3  email          day 2
Step 4  delay 3 days
Step 5  email          day 5

Two more rules save time later. Use hours for anything in the first day and days for everything after, because the unit records what you meant. And never put two email steps next to each other with no delay between them: both go out in the same minute, and the second buries the first.

Overlapping automations#

This is the failure that reaches recipients rather than showing up in your numbers.

Here is the shape of it. Someone subscribes on Monday and enters your twelve-day welcome series. On Wednesday they download a guide, which writes a field, which triggers a second automation with its own three emails. Neither automation knows about the other. On Thursday morning the contact gets two emails from you within a minute of each other. On Saturday it happens again.

Nothing in either automation is wrong on its own. The problem exists only in the overlap, which is why it survives testing: you tested each automation separately.

How to avoid it

Mark membership with a field. When a contact enters an automation, set a field, for example in_sequence, to the automation's name. Clear it at the end, on every path including branches that exit early. Then start every automation with a condition that stops anyone who already has a value in that field. This is the pattern that reliably works, because it is checked at entry rather than depending on your memory.

Decide which sequence wins. When two automations can claim the same contact, write down which takes priority. Usually the one tied to a purchase or a deadline beats the one tied to education. The loser exits rather than queues.

Keep sequences short. A welcome series that runs for twelve days can only collide with things that happen inside twelve days. One that runs for eight weeks collides with everything.

List the automations on one page. Every active automation, its trigger, and its length in days. Most overlaps become obvious the moment two triggers the same person can satisfy sit next to each other.

Quiet hours#

An automation sends whenever the contact reaches the step, which can be 3am for that person.

For most sequences this does not matter, because the recipient sees it whenever they next open their inbox. It matters when the email is time-sensitive, or when a notification will wake someone up.

You can steer it with delays. A delay of 20 hours from an entry during the working day puts the next email in the following morning. Delays of whole days preserve the time of day the contact entered, which for a signup form is usually a reasonable hour already, because that is when people were awake to sign up.

Where the time of day genuinely matters, control the entry point rather than the send. Triggering from a segment you refresh at a chosen hour gives you what per-step scheduling would.

Two related points. Contacts spread across time zones cannot all get a 9am email from one delay. And a sequence starting on Friday delivers on the weekend, which is poor for business audiences.

If something goes wrong#

A contact received two emails at once. Check for a missing delay between two email steps, then check whether they are inside two automations at the same time.

Nobody enters a date-based automation. Check how many contacts have a value in that date field. An empty field never qualifies.

The same contact keeps re-entering. A field-change trigger whose value gets rewritten, usually by an import. Set a marker field on first entry and check it at the top.

Emails arrive later than the delay you set. Sends are queued, so a large simultaneous entry spreads out. Confirm against a single test contact, not a batch.