How To Use If/Else Branching In Email Automation

If/else branching is the decision-making layer in an email automation. It asks a question about a person, their account or an event, then sends them down one path when the answer is true and another when it is false.

For example: Has the customer completed account setup within seven days? If yes, stop sending setup reminders and move them into education or product-use messages. If no, send a practical reminder that helps them complete the next step.

That sounds straightforward, but a branch is only as good as the data, timing and safeguards behind it. A badly designed branch can send someone a “finish your purchase” email after they have paid, continue a promotional sequence after they unsubscribe, or multiply message frequency when several automations overlap. Good branching makes a programme more relevant; it does not simply make it more complicated.

What if/else branching means in an email journey

An if/else branch evaluates a condition at a particular point in an automation:

• If the condition is met, the person follows the “yes”, “true” or matching path.
• Else they follow the “no”, “false” or non-matching path.

Most journey builders support this pattern, although the labels vary: conditional split, decision split, true/false branch or action path. Conditions commonly draw on profile attributes, segment membership, message activity and events. For example, Customer.io’s true/false branch documentation describes conditions based on attributes, events, segments, messages and related objects.

The decision is usually evaluated when the recipient reaches the branch, not necessarily when they entered the automation. This distinction matters. Someone may enter a trial onboarding journey on Monday, upgrade on Wednesday and reach a plan-status branch on Friday. In most sensible designs, the Friday decision should use their status on Friday.

Some platforms provide more than two paths for values such as country, subscription tier or product category. That is useful where paths are genuinely different. But an if/else branch remains the clearest starting point because it forces an important question: what should happen to everyone who does not meet the condition?

Branching is different from conditional content

These features are related but solve different problems.

Use case	Better approach
The email is the same, but the product image, greeting or help link differs.	Conditional content within one email.
The recipient needs a different message, different delay, different channel or should leave the journey.	An if/else branch.
The recipient is no longer eligible to receive any further marketing in the journey.	An exit rule, suppression or send-level eligibility check.

Keeping a small difference inside one message reduces maintenance and makes reporting easier. Branch when the customer’s next action should materially change. For instance, a customer who has already redeemed an offer should not merely see a different offer block; they may need to exit the offer journey entirely.

Choose conditions that can support a real decision

Start with the decision, then identify the evidence needed to make it. Avoid starting with every available field in the platform. The best branch conditions are connected to a clear customer need and are based on data that is accurate enough, timely enough and consistently defined.

Profile and account data

Attributes such as language preference, plan type, region, customer status or known product ownership can work well when they are maintained by a reliable source of truth.

For example:

• If the customer’s plan is “free”, send a feature education email; else, send a message about a feature available on their paid plan.
• If the preferred language is set, use the relevant language journey; else, use the default language or ask for a preference.

Be precise about missing and stale values. “Plan is not premium” is not necessarily equivalent to “plan is free”: it could also mean the data is absent, the account has lapsed or an integration has failed. Where those states need different treatment, model them explicitly rather than allowing the else path to become a catch-all for data problems.

Events and milestones

Event-based conditions are often stronger because they represent an action: completed purchase, created first project, attended a webinar, downloaded a guide or submitted a form. Define the event carefully, including its time window and qualifying properties.

A useful onboarding condition might be: Has completed “first_project_created” at least once since entering this journey? That is far more specific than asking whether the person has ever been active. It also prevents historic activity from being mistaken for progress in the current onboarding period.

For commerce, a recovery sequence should normally check the latest state before each send. A cart event alone does not prove that a cart remains abandoned. If the person purchased, emptied the cart, started a newer checkout or has an unresolved payment issue, the appropriate route may differ.

Message engagement

Clicks on a meaningful link can be useful branching evidence. A click on “book a demo”, “view pricing” or “read the installation guide” expresses a clearer intent than an email open.

Be cautious about branching on opens. Apple’s Mail Privacy Protection can prevent senders from knowing whether a recipient opened a message, so an apparent open may not represent a deliberate read. Apple states that the feature prevents senders from seeing whether an email has been opened. Apple’s Mail Privacy Protection guidance explains the limitation. Google also says it does not track open rates or verify the accuracy of third-party open-rate reporting. Google’s email sender guidelines are clear on this point.

That does not mean opens have no analytical value at all. It means “did not open” is a weak basis for a high-stakes decision, such as deprioritising an engaged customer or escalating email frequency. Prefer clicks, on-site events, purchases, support activity and explicit preferences where possible.

Set the evaluation moment and wait window

A branch based on behaviour needs enough time for that behaviour to happen. If an email invites someone to read a guide and the automation checks for a click five minutes later, the “else” path mostly measures timing rather than lack of interest.

Use a deliberate delay or waiting period between the message and the decision. The right length depends on the action:

• A confirmation or account-security action may warrant a short window.
• A product setup task may need several days.
• A considered B2B purchase decision could need longer, but should not automatically trigger a dense sequence while the customer is deciding.

Platform guidance illustrates the principle. Mailchimp recommends placing at least a four-hour delay before a conditional split based on interaction with a previous email, giving contacts time to open or click. Mailchimp’s conditional split guidance also notes that branches can use audience data, campaign activity and segmentation criteria.

Document the rule in plain English alongside the technical condition. For example: “Wait five days after the welcome email, then check whether the recipient has created a project since journey entry.” This makes the intended behaviour reviewable by marketing, product, customer support and engineering teams.

Design the else path deliberately

The else path should not be an afterthought. It represents everyone who did not meet the condition, which may be a large and diverse group.

Consider a branch asking whether someone clicked an invitation to a live product session. People on the else path may include recipients who never saw the email, people who saw it but were busy, those who prefer self-service learning, and people for whom the session is irrelevant. Treating all of them as disinterested can produce an unhelpful follow-up.

A better else route might offer an on-demand guide, a short practical tip or no further message at all. The goal is not to force a conversion from every branch. It is to offer a sensible next experience.

When the false path is really several distinct states, add a further branch only if the resulting action differs. For example:

1. Has the customer completed setup?
2. If no, do they have an active account and permission to receive the relevant email?
3. If yes, send setup help; if no, exit or route to the appropriate operational process.

Protect eligibility, consent and contact pressure throughout the journey

Entry criteria alone are not enough. A person’s consent, account status and recent contact history can change after they enter an automation. Important eligibility checks should be applied at the point of sending as well as at entry, particularly in longer journeys.

At a minimum, determine how the automation handles:

• unsubscribes and global marketing suppression;
• hard bounces, complaints and invalid addresses;
• customers who have converted, cancelled or become ineligible;
• active support or complaint cases where promotional contact would be poorly timed;
• messages already scheduled or sent by overlapping journeys.

A contact-pressure rule is especially important where several programmes can act on the same person: welcome, abandoned basket, replenishment, win-back and campaign promotion. Without coordination, each flow may be logical on its own while the combined experience feels excessive.

This is also a deliverability issue. Mailbox providers assess more than technical authentication; persistent unwanted or poorly targeted mail leads to complaints and weaker sender reputation. Google advises senders to monitor spam rates, reputation, authentication and delivery errors in Postmaster Tools, and its dashboards explain that user-reported spam rate is only one part of the picture. Google’s Postmaster Tools dashboard documentation provides the relevant definitions and limitations.

For programmes with delivery problems or a complex estate, Email Foundry’s work on audience verification, suppression, contact-pressure controls and provider-level sending patterns can be relevant before expanding branching logic. More branches do not compensate for weak audience eligibility or an unhealthy sending programme.

Prevent branch collisions and re-entry problems

A single person can qualify for several automations in a short period. Before publishing, decide whether they can enter the journey more than once, whether they can be in related journeys at the same time, and what happens if the trigger fires again.

Common protections include:

• Conversion exits: end a cart-recovery journey as soon as the qualifying order is completed.
• Re-entry limits: allow a person back into a journey only after a defined period, or only for a genuinely new event.
• Mutual exclusions: prevent a high-priority service or account message from being accompanied by promotional nudges.
• Journey-scoped data: retain the context of the event that began this particular journey, rather than relying solely on an ever-changing profile field.

Journey-scoped context is valuable when several records are possible. If a customer can have more than one order, project or subscription, a generic field such as “last order status” may be overwritten before the branch is reached. Store or pass the relevant order ID, project ID or event timestamp with the journey, then evaluate the condition against that specific context.

Test the logic as paths, not just emails

A polished email preview does not prove the automation works. Test each route using controlled profiles or test events, and inspect the journey history where the platform provides it. Customer.io, for example, documents journey histories that show a person’s pathway, deliveries and exits, which is useful for finding why someone did not progress as expected. Its automation journeys documentation describes this troubleshooting view.

Test more than the ideal yes and no cases:

• a matching customer with complete data;
• a non-matching customer with complete data;
• a customer whose key field is empty, malformed or delayed;
• a customer who converts during a delay;
• a customer who unsubscribes after entry;
• a repeat trigger or overlapping automation;
• boundary times, including time zones and the exact expiry of a wait window.

Give branches descriptive names. “Clicked pricing email within five days” is easier to audit than “Decision split 4”. Keep a simple decision map outside the automation tool that records the trigger, condition, data source, evaluation timing, message purpose, exit conditions and owner. It becomes invaluable when someone asks why a particular email was sent.

Measure whether the branch improves the customer experience

Do not judge a branch solely by the immediate click rate of one path. Look at the outcome it was built to support: completed setup, retained subscription, successful purchase, fewer support contacts or reduced unnecessary messages. Then check for side effects: complaints, unsubscribes, delivery errors and rising pressure on the same audience.

Compare against a meaningful baseline where possible. If the change is substantial, hold out a small eligible group from the new logic or run a controlled test. A random split can be appropriate for experiments, but it is not an if/else decision: random allocation tests alternatives, whereas a condition should route people according to information that makes one next step more appropriate.

Finally, review branches after launch. Data definitions change, products change and old branches accumulate. Remove routes that no longer have a clear purpose. The most effective automations are usually comprehensible enough for a new team member to explain what each decision does, why it exists and how a recipient can leave it.

Frequently asked questions

Should I branch email automations based on opens?

Use open data cautiously. Privacy features and mailbox behaviour can make opens unreliable as proof of deliberate engagement. A meaningful click, product event, purchase, preference update or account milestone is normally a stronger condition.

When should an automation evaluate an if/else condition?

Usually when the person reaches the branch. Add a sensible wait period after the message or event you want to assess, and define whether the condition should consider activity since journey entry, since the last message or over the person’s full history.

What should happen in the else path?

Design it deliberately. The else path may contain people who were busy, did not receive the message, lacked the relevant data or were simply not interested. It may need a different form of help, a longer wait, another eligibility check or an exit rather than another promotional email.

How can I stop people receiving conflicting automated emails?

Use conversion exits, re-entry rules, global suppression, send-level eligibility checks and contact-pressure controls. Review related automations together, rather than assuming each journey operates in isolation.

Sources and further reading

• Google email sender guidelines — Google
• Google Postmaster Tools dashboards — Google
• Apple Mail Privacy Protection guidance — Apple
• Mailchimp conditional split rules — Mailchimp
• Customer.io true/false branches — Customer.io
• Customer.io automation journeys — Customer.io