Drip Campaign:
Set Entry, Branch, Exit, and Re-Entry Rules

The emails are only the visible edge of a drip campaign. Behind them is a state machine that decides who enters, what timing or behavior changes the path, what counts as success, when to exit, and whether anyone may return. If those rules are vague, polished copy only makes an unreliable automation more persuasive.

A drip campaign is a path through states: an eligible event starts it; timing, decisions, actions, goals, exits, and suppression determine what remains valid. The sections define each control before the test combines them.

Drip’s workflow documentation distinguishes triggers, goals, actions, decisions, delays, and exits. Mailchimp’s automation-flow overview similarly describes trigger-based flows with rules, actions, and branches.

Different platforms use different labels, but a working drip campaign needs an entry event, path logic, actions, timing, and a defined way to stop or complete.

Drip campaign, broadcast, and nurture#

A broadcast sends one message to an eligible audience at a scheduled time. A drip campaign moves each eligible person through a predefined flow relative to an entry event. A nurture program is a broader objective—helping an audience progress through education or evaluation—and may contain drip campaigns, broadcasts, human follow-up, and product experiences.

The distinction determines governance: a broadcast has one release time, a drip has a clock and state per entrant, and nurture can coordinate automated and human work. “Automated” does not mean perpetual or unsupervised. Every automation needs an owner, a release state, a change history, and a safe stop.

Entry is where the campaign’s clock begins#

Entry establishes why this person may start and which clock applies. Its rule combines an event or condition with eligibility. Examples include:

• a permissioned resource registration;
• creation of a trial account;
• completion of an onboarding milestone;
• a renewal window for an existing customer; or
• a defined inactivity condition under an approved communication policy.

Write the rule as a testable contract:

enter when: qualifying event occurred
and: audience eligibility is true
and: required permission or lawful basis is documented
and: global and campaign suppression are false
and: re-entry rule allows this occurrence

The event time and processing time can differ. A delayed integration may enter someone after the context has changed. Set a maximum event age and decide whether late events are ignored, routed to a different path, or reviewed.

“Added to a list” is not a complete entry reason. Preserve the original event, time, source, eligibility, permission context, and rule version.

Sequences are ordered state changes, not a pile of emails#

A sequence maps the current state to an allowed next state. It can contain messages, delays, data updates, notifications, and handoffs. Every step needs:

• an intended recipient state;
• the action or message;
• a clock definition;
• pre-send eligibility and suppression checks;
• success or progression evidence;
• failure and retry behavior; and
• the next valid states.

Calendar delays and elapsed-time delays are not always equivalent. “Wait two days” can mean 48 hours, the second business day, or the next permitted send window. Time zone, daylight changes, holidays, and quiet hours can matter. Use the exact behavior supported by the platform and test boundary cases.

An ideal delay or message count cannot be borrowed across campaign jobs. A security setup sequence, an event reminder, and a long buying-cycle education program have different clocks and different reasons to stop.

Branches make assumptions executable#

A branch makes one declared distinction and routes the person accordingly. Common inputs include role, account state, product action, prior message interaction, opportunity status, or explicit preference.

Use branch conditions that are:

• available before the decision executes;
• sufficiently reliable for the consequence;
• documented with null and unknown behavior;
• re-evaluated or deliberately fixed at a known time; and
• permitted for the use.

Do not use a weak proxy as if it were intent. An email click shows that a tracked link was activated under the system’s definition; it does not prove purchase readiness. A missing field is not automatically “no.” Route unknown values explicitly.

Goals and exits solve different problems#

A goal records desired progress, such as completing setup or scheduling a qualified conversation. An exit removes a person when continuing is no longer appropriate. The final step can also end a workflow. These are distinct reporting outcomes.

Drip separately documents workflow exits, which can remove people when configured conditions are met.

Exit behavior is part of the workflow’s execution logic. It should be configured and tested, not assumed from the final visible message.

Define at least these exit conditions:

• permission withdrawn or unsubscribe recorded;
• hard delivery failure or global suppression;
• person no longer belongs to the eligible audience;
• desired goal achieved;
• opportunity or customer state makes the message inappropriate;
• campaign expiration reached; or
• safety, privacy, legal, or operational pause activated.

An exit must also specify downstream effects. Does it cancel scheduled messages? Preserve history? Remove the person from only this flow or all marketing? Change a CRM field? The answer is platform- and policy-specific.

Re-entry and collision rules prevent automation debt#

Re-entry and collision govern repeat or concurrent paths. Some events can legitimately happen more than once. A person might attend several events or create multiple workspaces. Others should trigger only one onboarding sequence.

Choose one rule:

• never re-enter;
• re-enter once per distinct object or event ID;
• re-enter after a cooling period if eligibility remains true; or
• exit the current instance and restart from a named state.

Then define collision priority. A customer should not receive an acquisition message because an old lead field changed. A service incident may pause promotional automation. A human sales conversation may suppress or alter a generic sequence.

Create a central precedence table for global suppression, transactional notices, customer service, onboarding, renewal, sales-assisted evaluation, and promotional nurture. Do not let each campaign invent its own priority.

Permission and unsubscribe are execution controls#

The FTC’s CAN-SPAM compliance guide states that covered commercial email must provide a clear opt-out mechanism and that opt-out requests must be honored within 10 business days.

For commercial email subject to U.S. CAN-SPAM, opt-out is a concrete operational requirement. Other jurisdictions and message contexts can require different or additional permission and consent controls.

Make that obligation executable. Do not design to the outer legal deadline. Suppression should be checked at execution so a queued message does not continue after the system records a withdrawal. Obtain qualified legal review for the jurisdictions, audiences, and message types involved.

Test the state machine, not only the emails#

Definitions are not release evidence. This sequence maps the components, exercises failure paths, and assigns post-release ownership.

1. Name the audience progress — Define the legitimate job of the campaign and the observable state it may help change. Exclude people for whom the sequence is not relevant.
2. Write entry and identity contracts — Specify the event, source, age, subject or account, permission, suppression, duplicate handling, and re-entry key.
3. Draw states before messages — Map entry, waits, actions, branches, goals, exits, errors, and terminal states. Give null and late data their own behavior.
4. Write every message from its state — State what the recipient already did, what new value the message provides, why the timing is appropriate, and which accurate action follows.
5. Test synthetic traces — Run eligible, ineligible, unsubscribed, duplicate, late-event, missing-data, goal-completed, hard-bounce, and human-handoff cases. Verify history and downstream writes.
6. Release to a bounded cohort — Monitor entries, sends, suppression, branches, goals, exits, errors, complaints, and downstream progress under declared definitions.
7. Review and retire — Assign an owner and expiry trigger. Pause when the product, offer, policy, audience, or source data changes enough to invalidate the path.

Three campaign jobs built from the same controls#

These are not templates or performance claims. They show the controls serving three different audience states.

Onboarding: enter on verified account creation; branch on a meaningful setup event; provide relevant guidance; exit on the setup-completion goal, account closure, or suppression.

Evaluation education: enter after a permissioned resource request; sequence evidence around the declared topic; branch on explicit role or product activity; exit to a person on a qualified-conversation request, or exit when eligibility is lost.

Re-engagement: enter after a precisely defined inactivity period for an eligible customer; confirm the account remains active; offer product context or preference control; exit on return, decline, suppression, or campaign expiry.

Frequently asked questions#