Drip Campaigns Explained: How Entry Rules, Sequences, Branches, and Exits Work

A drip campaign is an automated sequence of messages and actions that begins when a person meets an entry rule. Timing, behavior, decisions, goals, exits, suppression, and re-entry determine what happens next. The emails are visible; the state machine behind them is the campaign.

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.

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.

“Automated” does not mean perpetual or unsupervised. Every automation needs an owner, a release state, a change history, and a safe stop.

Entry rules decide who enters—and what the clock means#

An entry 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.

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

A sequence 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.

There is no universal ideal delay or number of messages. A security setup sequence, an event reminder, and a long buying-cycle education program have different time constraints and reasons to stop.

Branches make assumptions executable#

A decision branch evaluates data or behavior and sends people to different paths. Common branch 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 often represents desired progress, such as completing setup or scheduling a qualified conversation. An exit removes a person when continuing is no longer appropriate. A workflow can also end because the final step completed.

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

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#

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.

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.

Build and test the campaign as a state machine#

Three illustrative flows#

These are logic examples, not performance claims.

Onboarding: enter on verified account creation; branch on a meaningful setup event; send relevant guidance; exit on setup completion, 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 when the person requests a qualified conversation or becomes ineligible.

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

Frequently asked questions#

What is a drip campaign?#

It is an automated flow that starts from an entry rule and progresses through timed actions, decisions, branches, goals, and exits.

How is it different from a newsletter?#

A newsletter is commonly a scheduled broadcast to an eligible audience. A drip campaign runs relative to each person’s entry event and state.

What can trigger a drip campaign?#

A documented event or state such as account creation, registration, a product milestone, a renewal window, or bounded inactivity—combined with eligibility, permission, suppression, and re-entry rules.

How many emails should be in a drip campaign?#

No universal number is supported. Include only the steps that provide timely value or support a defined transition, and set an end.

When should a contact exit?#

At minimum, when permission is withdrawn, suppression applies, eligibility ends, the goal is reached, the campaign expires, or continuing would conflict with a more relevant state.

Can someone re-enter a drip campaign?#

Only under an explicit rule tied to a new valid event, object, or cooling period. Define whether an existing instance continues, ends, or restarts.