GoHighLevel Router Action: A Step-by-Step Lead Routing Setup

The GoHighLevel Router action landed on October 29, 2026, and it fixes a quiet problem that costs small businesses real leads. Until now, when a lead asked for two or three things on one form, an If/Else branch sent them down the first matching path and ignored the rest. Router checks every branch and runs each one that matches, in an order you choose. In this setup breakdown, I'll walk you through one complete lead routing workflow, from the form question to the fallback branch, the test run and the go-live checklist. You can copy it into your own sub-account today.

TL;DR

• What changed: HighLevel added a Router workflow action. It runs every branch a contact matches, one after another, left to right. If/Else only runs the first match.
• Three branch types: Custom rules (runs when conditions match), Always run (runs for every contact) and Fallback (runs only when nothing else matched).
• What we build here: one inbound form with a multi-select "What do you need?" question. The Router sends the lead to every team that matches, logs a note for everyone, and catches odd leads in a fallback branch.
• The safe way to launch: build it in a copy of your workflow, test it with Test workflow on a real event, read the Passed / Not passed reasons, then publish.
• Biggest mistakes to avoid: using Router where only one outcome should happen, sending the same message twice from two branches, and forgetting the fallback.
• Status note: HighLevel has not said which plans get Router or whether rollout is complete, so check your own account first.

Key terms in plain English

Before we build, here are the words I'll use. Keep this list open if you're new to GoHighLevel workflows.

• Workflow: an automation in GoHighLevel (Automation > Workflows). It starts with a trigger and runs a list of actions for a contact.
• Trigger: the event that starts the workflow, such as "Form Submitted".
• Action: one step the workflow does, such as add a tag, assign a user, send an internal notification or create a task.
• If/Else action: a decision step. It checks conditions and sends the contact down the first branch that matches. If nothing matches, the contact goes down the "None" branch.
• Router action: the new decision step. It checks every branch and runs each one that matches, one after another, left to right.
• Branch: one path inside a Router or If/Else step, with its own actions.
• Custom rules branch: a Router branch that runs only when its conditions under "Only continue if" are true.
• Always run branch: a Router branch that runs for every contact, with no conditions.
• Fallback branch: a Router branch that runs only when no other branch matched.
• Multi-select field: a form field where the lead can tick more than one option (for example, a checkbox list of services).
• Test workflow: HighLevel's way of running a workflow on a real contact or event and seeing what each step did before you publish.

What is the GoHighLevel Router action?

The GoHighLevel Router action is a workflow decision step that sends one contact down every branch it matches, instead of only the first one. Branches run one after another, left to right, and you can drag them to change the order. It supports Custom rules, Always run and Fallback branches, and you can test it on a real event before publishing.

HighLevel announced it on its changelog on October 29, 2026, as a new action "in the same family as If/Else, with one big difference." The difference is simple but important. If/Else stops at the first match. Router keeps going.

Here's what HighLevel says the Router gives you:

• Every matching branch runs. If a contact matches three branches, all three run.
• Three branch types: Custom rules, Always run and Fallback.
• Familiar conditions. You set rules under "Only continue if", pick a field, choose an operator and add more conditions or rule groups.
• As many branches as you need.
• You control the order. Branches run left to right, and you can drag a branch in the Branches list to make it run first.
• Testable on a real event. When you test the Router with Test workflow, the output lists every branch condition as Passed or not, with the reason and the actual value the contact had.

Two "good to know" notes from HighLevel matter for setup: branches run one after another, not at the same time, and a Fallback branch runs only when no other branch matched.

How is Router different from If/Else in GoHighLevel?

If/Else sends a contact down the first branch whose conditions are true and skips the rest, even if the contact matches them too. Router evaluates every branch and runs each one that matches, in left-to-right order. Use If/Else when only one outcome should ever happen. Use Router when one lead can genuinely need several things.

HighLevel's own If/Else help article describes it as a step that "splits a workflow into multiple branches based on whether conditions are met," with an automatic None branch that runs when no conditions are met and can't be removed. That design works well for "either/or" choices. It works badly for "and also" choices.

Here's a quick side-by-side:

A real example helps. Say your form asks "What do you need?" and a lead ticks Website and CRM setup. With If/Else, if the Website branch is first, the CRM team never hears about this lead. To work around it, people built duplicate workflows or long chains of If/Else steps. HighLevel calls this out directly: one Router "replaces the copies of the same logic you built to catch a second or third match."

When should a small business use Router instead of If/Else?

Use Router when one contact can qualify for more than one independent next step, such as several services, several teams, or several follow-up sequences. Keep If/Else when the outcomes must not overlap, like "book a call or send a price list." If a contact should only ever get one message, Router is the wrong tool.

Here are situations where I'd reach for Router:

• Multi-service enquiries. A lead asks for two services. Each service team should get the lead with its own task and notes.
• Agencies with several departments. A lead wants ads, a website and email marketing. Each department owner gets assigned work.
• Tagging for reporting. You want to tag a lead with every interest they showed, not just the first one, so your reports are honest.
• Notes plus action. You want an "Always run" branch that logs a summary for every lead, while the custom branches do the real routing.
• Catch-all safety. You want a Fallback branch that flags leads that didn't match anything, so nobody falls through the cracks.

And here's where I'd not use Router:

• One outcome only. "If budget is high, book a call; otherwise send a guide." That's If/Else.
• Customer-facing messages that could stack. If three branches each send an SMS, the lead gets three texts in a row. That feels spammy. Keep customer messages in one place (more on this below).
• Splitting traffic for tests. HighLevel also released an A/B Test action on October 27, 2026, which splits contacts evenly across 2 to 10 paths. That's for experiments, not routing.

The setup we're building: one form, every team that matches

Let's build one complete, realistic workflow. This is an example setup, not a client project.

The business: a small agency (or any service business) that offers four services: Website, Ads, CRM & automation and Email marketing.

The form: one inbound enquiry form with these fields:

1. Name, email, phone (standard contact fields)
2. "What do you need?" — a multi-select (checkbox) field with the four services
3. "How soon do you want to start?" — a single-select dropdown: This month, In 1–3 months, Just researching
4. "Anything else we should know?" — a free-text field

The goal:

• Every lead gets one friendly confirmation message (not four).
• Every team whose service was ticked gets the lead: an assignment or task, an internal notification and a tag.
• Every lead gets a short internal note so whoever picks it up knows the full picture.
• Leads that tick nothing (or send odd data) are caught by a fallback branch and checked by a person.
• Urgent leads ("This month") get a faster internal task.

The final shape of the workflow:

Trigger: Form Submitted (Enquiry form)
  │
  ├─ Action: Send confirmation (email or SMS) ← once, before routing
  ├─ Action: Create/Update Opportunity (Pipeline: New enquiries)
  │
  └─ Router: "Route by service"
       ├─ Branch 1 (Custom rules): service includes CRM & automation
       ├─ Branch 2 (Custom rules): service includes Website
       ├─ Branch 3 (Custom rules): service includes Ads
       ├─ Branch 4 (Custom rules): service includes Email marketing
       └─ Branch 5 (Fallback): no other branch matched → manual review

Notice that the customer-facing message happens before the Router, once. The Router only does internal work. That one choice prevents most of the problems people will hit with Router in the first few weeks.

You might ask: why not an Always run branch for the internal note? You can. But in HighLevel's description, Always run and Fallback are both branch types, and I've chosen to keep the "for everyone" steps before the Router so the order is obvious and the Fallback logic stays clean. If you prefer the Always run branch, I show that variation in Step 7.

What do you need before you build the Router workflow?

You need a form with a multi-select field, users or teams to assign, a pipeline for new enquiries, a few tags, and a test contact you control. Set these up first. Building the Router without them means guessing field values later, which is where most routing bugs come from.

Here's the prep checklist:

1. The form and its fields. Create (or open) your enquiry form. Make sure "What do you need?" is a multi-select / checkbox field, and write down the exact option labels. Small spelling differences ("CRM & Automation" vs "CRM and automation") will break conditions.
2. Users. Decide who owns each service. If you're a one-person business, assign everything to yourself but still use separate tasks per service.
3. Pipeline. A pipeline called something like "New enquiries" with a first stage like "New lead".
4. Tags. One tag per service, such as interest-website, interest-ads, interest-crm, interest-email, plus needs-review for the fallback.
5. Confirmation message. One short email or SMS template that thanks the lead and says what happens next.
6. A test contact. Use your own email and phone so you can submit the form as a real lead without touching a customer.
7. A copy of any existing workflow. If you're replacing an old If/Else setup, duplicate it first. Build the Router in the copy, not the live version.

Once that's ready, building takes less time than you'd think.

Step-by-step: how to set up the GoHighLevel Router action

Step 1: Create the workflow and add the trigger

Go to Automation > Workflows and create a new workflow from scratch. Name it clearly, for example "Enquiry – route by service (Router)".

Add the trigger Form Submitted and filter it to your enquiry form. If you have several forms, this filter matters: without it, every form on the account will start this workflow.

Tip: In workflow settings, check how re-entry is handled. If a lead submits the form twice, decide whether they should go through routing again. For most service businesses, allowing re-entry is fine as long as your branches don't send customer messages (ours don't).

Step 2: Send one confirmation message before the Router

Add your confirmation action (Send Email or Send SMS) right after the trigger. Keep it short and human:

"Thanks, {{contact.first_name}}. We got your request and someone from the team will reply soon. If it's urgent, just reply to this message."

Why here and not inside the Router? Because Router runs every matching branch. If each branch sends a "thanks" message, a lead who ticks three services gets three. Put customer messages in one place, once.

Step 3: Create or update the opportunity

Add Create/Update Opportunity. Put it in your "New enquiries" pipeline at the "New lead" stage. Use the contact's name in the opportunity name so it's easy to scan.

Doing this before the Router means every lead ends up in the pipeline, no matter which branches run. Your pipeline becomes the single list of "who asked us for something," which is exactly what it should be.

Step 4: Add the Router action

Click the + after the opportunity step and add the Router action. Name it "Route by service".

You'll see the Branches list. This is where you add branches, choose each branch's type and drag them into the run order. Following HighLevel's own steps:

1. Open a branch and choose the branch type: Custom rules, Always run or Fallback.
2. For Custom rules, set conditions under Only continue if.
3. Click Add branch for each path you need.
4. Drag the branches in the Branches list to set the run order (optional).
5. Add the actions that should run inside each branch.

Step 5: Build the four service branches with Custom rules

Create four branches, each with the type Custom rules:

• Branch 1 – CRM & automation: Only continue if What do you need? includes "CRM & automation".
• Branch 2 – Website: Only continue if What do you need? includes "Website".
• Branch 3 – Ads: Only continue if What do you need? includes "Ads".
• Branch 4 – Email marketing: Only continue if What do you need? includes "Email marketing".

Use the operator your account shows for multi-select fields (it may be labelled "includes" or "contains"). HighLevel's own worked example uses this exact pattern: "the service includes HVAC", "the service includes Plumbing", and so on.

Name each branch after the service. When you read test results later, "Branch 3" is useless; "Ads" is instant.

Step 6: Add the internal actions inside each branch

Inside each service branch, add the same short set of internal steps. For the CRM & automation branch, for example:

1. Add Tag: interest-crm
2. Assign to User (or create a task for the owner of that service). If one lead can match several branches, think about assignment carefully: a contact has one owner, so if every branch reassigns the contact, the last branch to run wins. A safer pattern is to assign the contact once (before the Router, or only in your top-priority branch) and use tasks for every other team.
3. Add Task: "Reply to {{contact.first_name}} about CRM & automation", assigned to the CRM owner, due today or tomorrow.
4. Internal Notification: a short email or in-app alert to the CRM owner with the lead's name, chosen services and the "Anything else" answer.

Repeat for Website, Ads and Email marketing, changing the tag, task title and owner each time.

Why tasks instead of reassignment for everyone? Because Router runs branches one after another, left to right. Assignment is a single value on the contact. Tasks are not. With tasks, every team gets its own to-do, and nobody's assignment gets silently overwritten by the next branch.

Step 7: Add the internal note (two ways)

Your team should see one clear summary of the lead in the conversation. HighLevel added an Add Internal Comment workflow action in October 2026, which posts a private note into the conversation history that only your team can see.

Option A – before the Router (my default): add Add Internal Comment right after the opportunity step:

"New enquiry. Services: {{contact.what_do_you_need}}. Start: {{contact.how_soon}}. Notes: {{contact.anything_else}}."

(Use the custom value names your fields actually have; the ones above are examples.)

Option B – an Always run branch: add a branch with the type Always run and put the Add Internal Comment action inside it. Drag it to the far left so it runs first. This keeps all "after the form" logic inside the Router block, which some people find easier to read on the canvas.

Both work. Pick one, not both, or you'll get two notes.

Step 8: Add the Fallback branch

Add one more branch and set its type to Fallback. HighLevel is clear on the rule: a Fallback branch runs only when no other branch matched.

Inside it:

1. Add Tag: needs-review
2. Add Task: "Check this enquiry – no service selected", assigned to whoever triages leads.
3. Internal Notification to the same person.

When would this fire? When a lead leaves the services field blank, when someone renames a form option and the old condition no longer matches, or when a lead arrives with data you didn't expect. Without a fallback, these leads just sit in the pipeline with no owner and no task. With it, a person gets a nudge the same day.

Important: if you used Option B in Step 7 (an Always run branch), confirm in your test that your Fallback still behaves the way you expect for a lead with no services. Test it rather than assume, because "matched" is decided by HighLevel's engine, not by how the canvas looks.

Step 9: Set the branch order on purpose

Branches run left to right. Drag them in the Branches list into the order that matches your priorities. A good default:

1. (Always run note, if you used Option B)
2. Your most valuable or most time-sensitive service
3. The other services
4. Fallback (it only runs if nothing else matched, so its position doesn't change the logic, but keeping it last keeps the canvas readable)

Order matters most when branches change the same thing. If two branches both set the contact's owner or both move the opportunity to a stage, the later branch overwrites the earlier one. Either avoid that, or put the branch whose change should "win" further to the right.

Step 10: Add urgency handling without breaking the Router

You want "This month" leads to move faster. You have two clean options:

• Inside each service branch: add a small If/Else after the task: if How soon? is "This month", add an extra task due today and tag urgent. If/Else is perfect here because the outcome is either/or.
• As its own Router branch: add a Custom rules branch "Urgent" with How soon? is "This month", and put the urgent tag plus a same-day task for the lead owner inside it.

The second option is neater: one place for urgency, not four copies. Because Router runs every matching branch, a lead who wants Ads urgently will run both the Ads branch and the Urgent branch.

Step 11: Save, test on a real event, then publish

Save the Router action and the workflow, but don't publish yet. Testing is the next section, and it's the step most people skip.

How do you test a GoHighLevel Router workflow before publishing?

Submit your form as a test lead, then use Test workflow on that real event. The Router's test output lists every branch condition as Passed or not, with the reason and the actual value the contact had. Check each scenario: one service, several services, no service and urgent. Publish only after all four behave correctly.

HighLevel's Router announcement says you can "test the Router action with Test workflow on a real event" and that "the output lists every branch condition as Passed or not, with the reason and the actual value the contact had." That last part is gold for debugging. When a branch doesn't run, you see exactly what value the contact had and why the rule failed.

HighLevel also released a broader new way to test workflows on October 27, 2026 (available in HighLevel Labs at the time of writing), where you can test a single trigger or a single action with real events from your own account and then run the whole workflow step by step. If your account has it, use it.

Here's the test plan I'd run, using your own contact details:

For each test, check four places:

1. The Router test output (Passed / not, with reasons).
2. The contact record: tags, owner and the internal note.
3. Tasks: one per matching service, assigned to the right person.
4. Your inbox or phone: exactly one confirmation message.

If test 2 sends you two confirmation messages, a customer message slipped into a branch. Move it out.

If test 3 doesn't trigger the fallback, check whether some branch matched by accident (for example, a condition like "is not empty" on a field that always has a value).

When all five pass, publish the workflow. If you're replacing an older If/Else workflow, turn the old one to draft at the same time so leads don't run through both.

What are the most common Router mistakes?

The most common Router mistakes are sending customer messages from several branches, letting later branches overwrite the contact owner, skipping the fallback, using Router for either/or decisions, and publishing without testing a multi-match lead. Each one is easy to prevent with a little planning before you build.

Here they are with fixes:

1. Stacked customer messages. Three branches, three "thanks" texts. Fix: send customer messages once, before or after the Router, never inside multiple branches.
2. Owner ping-pong. Every branch runs Assign to User, so the last branch decides the owner. Fix: assign once, use tasks for the other teams.
3. No fallback. Leads with blank or odd data get nothing. Fix: always add a Fallback branch with a human task.
4. Router for either/or logic. A lead ends up in both "book a call" and "send a guide". Fix: use If/Else for mutually exclusive outcomes.
5. Exact-label drift. Someone renames "Ads" to "Paid ads" on the form, and the Ads branch silently stops matching. Fix: the fallback will catch these leads, but also add a note in your form description: "If you rename options, update the Router."
6. Long waits inside branches. Branches run one after another. If the first branch has a long Wait step, think about how that affects the branches after it, and test it. Fix: keep Router branches short and fast; put long follow-up sequences in separate workflows that each branch starts (for example, with an Add to Workflow action).
7. Testing with a single-service lead only. That's the one case If/Else already handled. Fix: always test a multi-match lead before publishing.

How does the Router compare with Zapier Paths and n8n Switch?

Zapier Paths and the n8n Switch node can both send one record down several matching branches, and Zapier now runs path branches sequentially, left to right. GoHighLevel's Router brings the same idea inside your CRM, so routing, tags, tasks and pipeline updates live in one workflow without an extra tool.

If you've used other automation tools, this will feel familiar:

• Zapier Paths: Zapier's help centre says that, depending on your conditions, "one, some, all, or none of your branches can run." It has the same three rule types: Custom rules, Always run and Fallback, and a fallback "will run if no other path branch's rules are met." Zapier also moved Paths to sequential execution, where branches run one by one in the order they appear (left to right).
• n8n Switch node: in Rules mode, the Switch node has an option called "Send data to all matching outputs." When it's off, an item goes only to the first matching output. When it's on, it goes to every output that matches.

So which should you use?

• If the lead lives in GoHighLevel, and the actions are GoHighLevel actions (tags, tasks, opportunities, notifications), use the Router. It's one less tool, one less connection and one less place for things to break.
• If the routing has to touch many outside apps (a project tool, an accounting app, a Slack channel per department), Zapier or n8n may still be the better hub. I compared the two approaches in GoHighLevel vs Zapier for small businesses.
• If you already run n8n, keep heavy data work there and let GoHighLevel handle the CRM side. My n8n 3.0 upgrade checklist covers keeping those flows stable.

Whatever you choose, the design rules are the same: one customer message, clear ownership, a fallback, and a test with a multi-match record.

How do you keep a Router workflow healthy after launch?

Check it weekly for the first month: look at the fallback tag count, failed or skipped steps, and whether every new lead has a task. HighLevel's new Workflow Maps can show workflow errors across a sub-account and a contact's journey across workflows, which makes these checks faster.

Routing is not "set and forget." Forms change, team members leave, services get renamed. Here's a light routine:

1. Weekly: filter contacts by the needs-review tag. A sudden jump usually means a form option changed.
2. Weekly: pick three new leads and check that each one has the right tags, one confirmation and one task per service.
3. After any form edit: re-run test 2 (multi-service) and test 3 (no service).
4. After any team change: update the users in Assign and Add Task actions. A task assigned to someone who left is the same as no task.
5. Use Workflow Maps when it's in your account. On October 27, 2026, HighLevel released Workflow Maps features to find and troubleshoot workflow errors across a sub-account and to follow an individual contact's journey across workflows. That's exactly what you need when someone says "this lead never got a reply."

If you want a deeper monthly routine across GoHighLevel, Zapier and n8n, my Zapier audit checklist works for any automation stack, and lead response time for small businesses explains why the speed of that first reply matters so much.

Is the Router action available on every HighLevel plan?

HighLevel's changelog doesn't say which plans or sub-accounts get Router, and an independent HighLevel news site notes that rollout status and plan gating are unconfirmed. Open Automation > Workflows in your sub-account and look for Router in the action list. If you can't see it yet, keep your If/Else setup running.

The independent site GoHighLevel News summed it up this way: HighLevel "has not confirmed which specific subscription tiers or sub-account types have access to this feature," and it recommends treating existing live workflows with caution until you've verified Router behaviour in a test workflow. That's good advice.

So until you've confirmed it in your own account:

• Don't delete working If/Else workflows.
• Build the Router version as a copy.
• Run the five tests above.
• Switch over only when the Router version passes.

A quick before-and-after: the old way vs the Router way

To make the value concrete, here's what the same goal looked like before Router existed.

Before (If/Else):

• One If/Else with four branches. A multi-service lead only reached the first matching team.
• To fix that, people either built four separate workflows, each with its own trigger and filter, or chained several If/Else steps one after another.
• Four workflows meant four places to update when anything changed, and a real risk of four confirmation messages.

After (Router):

• One workflow, one trigger, one confirmation, one Router.
• Each service branch adds its own tag and task.
• A fallback catches leads with nothing selected.
• The test output tells you exactly why each branch passed or failed.

HighLevel's own summary is a good one-liner: "One contact, every matching branch, in the order you choose."

Copy-ready build sheet

Here's the whole setup on one screen so you can build it with this page open.

Workflow name: Enquiry – route by service (Router)

Trigger: Form Submitted → filter: Enquiry form

Actions before the Router:

1. Send Email/SMS: one confirmation
2. Create/Update Opportunity: Pipeline "New enquiries", stage "New lead"
3. Add Internal Comment: summary of services, start date and notes
4. (Optional) Assign to User: default lead owner

Router: "Route by service"

Rules to remember:

• No customer messages inside branches.
• Assign the owner once; use tasks for other teams.
• Keep branches short; start long sequences in separate workflows.
• Test single, multi, none, urgent and re-submit before publishing.

One thing to watch with this table: the Urgent branch is a Custom rules branch, so if a lead is urgent but ticks no service, Urgent matches and the Fallback will not run. If you want blank-service leads always reviewed, add "What do you need? is empty" as its own Custom rules branch with the review task, or include that check in your triage routine. Test it either way.

FAQ

What does the GoHighLevel Router action do?

It sends one contact down every workflow branch whose conditions match, one after another from left to right. HighLevel added it on October 29, 2026. It's different from If/Else, which stops at the first matching branch.

Can a contact go down more than one branch in GoHighLevel now?

Yes, with the Router action. If a contact matches three Custom rules branches, all three run in the order shown in the Branches list. With If/Else, the contact still only goes down the first matching branch.

What is the difference between Always run and Fallback in the Router?

An Always run branch runs for every contact, with no conditions. A Fallback branch runs only when no other branch matched. Use Always run for shared steps like a note; use Fallback to catch leads that didn't fit any rule.

Do Router branches run at the same time?

No. HighLevel says branches run one after another, not at the same time, from left to right. You can drag branches in the Branches list to change which one runs first.

Should I replace all my If/Else steps with Router?

No. Keep If/Else for either/or decisions where only one outcome should happen. Use Router when a lead can need several independent things, like more than one service or more than one team.

How do I stop leads getting duplicate messages from a Router?

Keep customer-facing messages outside the Router. Send one confirmation before the Router, and use the branches only for internal work like tags, tasks and notifications. Then test with a lead that matches several branches.

How do I test which Router branches ran?

Use Test workflow on a real event. HighLevel says the Router test output lists every branch condition as Passed or not, with the reason and the actual value the contact had.

Is the Router action available in every HighLevel account?

HighLevel hasn't confirmed plan gating or full rollout. Check Automation > Workflows in your sub-account for the Router action, and keep existing If/Else workflows running until you've tested a Router copy.

Can I do the same thing in Zapier or n8n?

Yes. Zapier Paths can run one, some, all or none of its branches and supports Always run and Fallback rules. In n8n, the Switch node has a "Send data to all matching outputs" option. Router simply keeps this logic inside GoHighLevel.

What happens if I rename an option on my form?

Any Router condition that checks the old label will stop matching. That's why the Fallback branch matters: those leads get a review task instead of being ignored. Update the Router conditions whenever you edit form options.

Want this set up and tested in your account?

If your leads come in through GoHighLevel, Zapier, n8n or HubSpot and you're not sure every one reaches the right person, I can help. I'll review your current routing, rebuild it with the Router where it makes sense, test every scenario and leave it documented and monitored.

Start here: DM me the word "audit" on LinkedIn, or get in touch. I'll look at how your leads are routed and tell you what to fix first.

See how I build (these are demos and sample projects, not client results):

• GoHighLevel automation demo
• AI automation demo
• n8n reliability demo
• WhatsApp CRM demo
• n8n lead automation sample project

Packages:

• Starter, $399: delivered in 7 days
• Growth, $599: delivered in 14 days
• Full system, $899: delivered in 28 days

Care plans to keep everything running after launch, including monitoring and updates like this one: $80, $130 or $200 per month.

Related guides: GoHighLevel LevelUp 2026: 9 updates worth using, GoHighLevel appointment reminder workflow and HubSpot to GoHighLevel migration. More on the blog.

Sources

• HighLevel Changelog, "Router: New Workflow Action" (October 29, 2026): ideas.gohighlevel.com
• GoHighLevel News, "HighLevel Adds Router Workflow Action for Multi-Branch Execution" (October 29, 2026): gohighlevelnews.com
• HighLevel Support Portal, "Workflow Action - If/Else": help.gohighlevel.com
• GHL Weekly, "GoHighLevel updates: October 2026" (A/B Test action, Workflow Maps, new workflow testing): ghlweekly.com
• The Daily Level, "Social Planner post triggers in Workflows" (Add Internal Comment action, October 25, 2026): thedailylevel.com
• Zapier Help Center, "Add branching logic to Zap workflows with Paths": help.zapier.com
• Zapier Help Center, "Use conditional logic to filter and split your Zap workflows": help.zapier.com
• n8n Docs, "Switch" node: docs.n8n.io