If/Else branching in GHL workflows: when to reach for it and when to avoid it

Watch a GoHighLevel operator build their first serious nurture sequence and you can predict the shape of it. Message one. Then an If/Else: did they reply? Message two. Then an If/Else: did they reply yet? Message three. Then another one. By the end there are nine branches, six of which do exactly the same thing, and nobody including the person who built it can say with confidence what happens to a lead who books an appointment on day four.

If/Else is the most reached-for action in the workflow builder and the one that most reliably turns a maintainable automation into something nobody wants to touch. Not because branching is wrong. Because branching is expensive, and the price is invisible at the moment you add one.

This post is about where that price comes from, the four situations where a branch genuinely earns it, and the three GHL actions that do the job better most of the time.

What If/Else actually does

Mechanically it is simple. The action evaluates contact data and splits the workflow into branches. Inside a branch you set the field to evaluate, choose an operator, and set a comparison value. Per HighLevel's If/Else documentation, you click Add Segment to add additional conditions and use AND or OR to control how conditions are grouped, and you click Add Branch to define more condition groups.

Then there is the branch nobody designs. The same documentation states that the None branch is created automatically, that it runs when no defined conditions are met, and that this branch does not support conditions and cannot be removed.

Read that again with an operator's eye. Every If/Else you place in a workflow creates a path you did not write, that you cannot delete, and that catches every contact your conditions failed to anticipate. If you leave it empty, those contacts reach the end of it and stop. No error. No notification. No red flag anywhere in the builder.

That is the same category of problem as the invalid IDs that kill GHL automations without ever showing an error. GoHighLevel is consistently quiet about failure. An empty None branch is a lead disappearing on purpose, by a design decision you did not know you were making.

The real cost of a branch

A branch is not one more action. It is a permanent multiplier on everything downstream of it.

Testing surface doubles. One If/Else with a yes path, a no path, and the automatic None path is three complete journeys a real contact can take. Nest a second one inside a branch and you are not at four paths, you are at six or nine depending on where it sits. You cannot verify a workflow you cannot walk, and most agency owners stop walking somewhere around path four.

Size becomes unmanageable. Our own working rule, from building these across client accounts every week, is roughly 40 actions in a single workflow. Past that the builder becomes genuinely painful to work in and reviewing a change costs more than making it. That is our operating rule based on daily use rather than a limit HighLevel publishes, and branches are what push a workflow past it fastest, because a branch duplicates message actions instead of reusing them.

Every branch is another place a stale ID can hide. Actions inside branches reference pipelines, stages, custom fields, and users by ID. Clone that workflow into another sub-account and those references travel with it whether or not the target account has them. A dead ID inside branch three does not announce itself, it just quietly stops that path. It is the same mechanism that makes snapshots break on the way into a new account, and branching multiplies your exposure to it because there are simply more references to get wrong.

Branches hide unfilled custom values. This one we proved in our own testing on August 10, 2026, and it changed how we review workflows. We published a workflow whose SMS bodies all referenced a custom value that we had confirmed was empty first. GoHighLevel accepted the publish on the first attempt, returned published status, and raised no asset warnings at all. For contrast, a workflow missing a required notification recipient is blocked loudly at publish with a missing required fields error. So the platform is capable of stopping you. It just does not stop you for this one, and the failure reaches a real contact as a raw merge token in a real message. The more branches you have, the more message bodies there are to check by hand.

Four times If/Else is the right call

Branching is not the enemy. Branching for state is. These four earn their keep:

1. The paths do genuinely different work. A new patient lead and a reactivation lead should get different copy, a different offer, and a different pipeline. That is not a state check, that is two audiences who happen to enter through the same door.
2. Routing and assignment. Which rep owns this, which pipeline it lands in, which location handles it. The decision is made once, at entry, and everything after it is linear.
3. The guard clause at the top. One condition, evaluated immediately, that decides whether the contact belongs in this workflow at all. Wrong tag, wrong source, already a client: exit. Cheap to test because it runs before anything else and there is nothing downstream to interact with.
4. A data-quality gate before an action that needs the data. Do not fire an SMS action at a contact with no phone number, and do not fire an appointment reminder built on a custom field that is empty. Check the field, then act. This is the one branch that reliably prevents a visible failure instead of creating one.

Notice the pattern. All four decide something once, near the top, and then get out of the way. None of them re-ask a question the workflow has already asked.

Three actions that beat a branch

Most of the branches in a typical GHL workflow are answering one of three questions, and each has a purpose-built action that does it better.

"Did they reply?" is a Wait, not a branch

Per HighLevel's Wait action documentation, Wait can hold a contact until a condition is met, such as a contact replies or a specific event occurs. It holds the contact until they reply on a selected channel such as SMS or Email, with a timeout you can toggle on and configure, and it can also hold until a custom segment built from any of your fields evaluates as true.

That is the entire branch you were about to build, as one action, with no None path to maintain.

For a nurture sequence there is something better still. HighLevel's workflow settings documentation describes Stop on Response as ending the workflow for a contact if they respond to a message sent from that specific workflow, and notes it only ends the workflow for the contact who responded rather than affecting anyone else. Turn that on and your sequence becomes a straight line of messages with no reply checks in it at all. The house pattern we use is exactly that: a linear sequence, Stop on Response enabled, and separate small exit workflows that handle what happens after someone engages.

"Did they convert?" is a Goal Event

An If/Else evaluates once, at the instant the contact arrives at it. A Goal Event listens the whole time. HighLevel's Goal Event documentation states that when a contact meets the goal condition, for example clicking a link or submitting a form, the system instantly moves them to the defined goal step regardless of where they were in the workflow.

That single action replaces the check-after-every-message pattern outright. The constraint to design around is that the same documentation states only one Goal Event action can be added per workflow, and that once a contact meets it they are not re-evaluated for it in that workflow. So spend it on the one outcome the sequence exists to produce, usually the booking or the purchase, and let everything else be handled by tags and exits.

"Send them somewhere else" is a Go To, with one hard rule

The Go To action jumps a contact to another point in the workflow, which is useful for routing through another branch or sending someone back a few steps. HighLevel's Go To documentation is explicit about the restriction: the Go To action can only be added as a last step of a workflow or a branch, and it cannot be added between actions.

Design around that from the start. Go To is how you converge two branches back into one shared sequence instead of duplicating six actions into both sides, but only if each branch ends where you want to jump from.

The rule we actually use

Branch when the two sides do different work. Do not branch to represent a state change.

The test is quick: if both branches are doing the same thing three actions later, that was never a branch. It was a wait, a goal, or a tag. Collapse it.

And when the two paths stay different all the way to the end, that is usually not a branch either. It is two workflows. Separate workflows are easier to test, easier to publish independently, and far easier to hand to a client without explaining a diagram. Our standard build is a linear main workflow plus small exit workflows of about four actions each: remove from workflow, add a note, apply a tag, notify the owner. Anything that would have been a large branch becomes an exit workflow with a name you can read in a list.

How to audit a branch before a real lead hits it

Before publishing anything with branches in it, walk this list. All five are things GoHighLevel will not tell you on its own.

• Open the None branch on every If/Else. Decide deliberately what happens there. If the answer is "nothing," make that a real decision with a tag on it so those contacts are findable later, not an empty path.
• Verify every ID referenced inside every branch exists in this sub-account. Pipelines, stages, custom fields, users. Not the account you cloned from. This one.
• Enumerate the custom values every branch message references and confirm each has a value. Publish success is not evidence they are filled. We proved that directly, and it is the failure most likely to reach a customer.
• Count the actions. If the total is climbing past 40, the branches are the reason. Split them out into exit workflows before publishing rather than after.
• Walk each path end to end as if you were the contact. If you cannot narrate what happens on every path in one sitting, the workflow is too branched to maintain, regardless of whether it works today.

That last one is the honest test. Complexity you cannot narrate is complexity you will not maintain, and an automation nobody will touch is one that slowly stops matching what the business actually does.

How we run it

GHL Command is what I built to stop doing that audit by hand across my own brands and client accounts. It runs from Claude on your own machine, and it reaches the workflow builder layer that most GoHighLevel integrations cannot touch, so branch logic, triggers, and cloning are things you can inspect and change rather than things you go do manually in a browser tab afterward.

In practice that means asking for the audit instead of performing it: which workflows have branches whose actions point at IDs that do not exist in this sub-account, which have empty None branches, which are past a sane action count, and what a workflow will actually do before a client's lead finds out. It works the same way across every sub-account you manage, which matters because branch problems are usually inherited from a clone rather than authored fresh. We wrote about that portfolio view in running 20 sub-accounts from one console.

Flat $97 a month, every sub-account you manage included, never billed per account.

Frequently asked questions

What happens to a contact when no If/Else condition matches?
They go down the None branch, which HighLevel documents as created automatically, running when no defined conditions are met, not supporting conditions, and not removable. If it is empty, the contact stops there silently. Put a tag on that path so those contacts stay findable.

Should I branch to check whether someone replied?
Usually no. HighLevel documents that a Wait action can hold a contact until they reply on a selected channel with an optional timeout, and that Stop on Response ends the workflow for a contact who responds to a message from that workflow without affecting anyone else. Either one removes the branch entirely.

How many branches is too many?
HighLevel does not publish a branch limit, so the real limit is what you can test. Our own rule from daily builds is about 40 actions per workflow, then split into exit workflows. That is our operating guidance, not a documented platform ceiling.

Goal Event or If/Else?
An If/Else evaluates once when the contact reaches it. HighLevel documents that a Goal Event instantly moves a contact to the goal step regardless of where they were, which replaces checking the same condition repeatedly. Only one Goal Event is allowed per workflow, so spend it on the outcome the sequence exists to produce.

Do branches make cloning between sub-accounts riskier?
Yes. Every action inside a branch can reference a pipeline, stage, custom field, or user by ID, and those references do not validate themselves in the new account. Verify each one against the destination sub-account before publishing. See the map of what the 57 native triggers can and cannot do for the same problem on the entry side of a workflow.