GoHighLevel workflows vs triggers vs campaigns: build workflows, and here is why

What is the difference between workflows, triggers, and campaigns in GoHighLevel?

A workflow is GoHighLevel's current automation builder, a trigger is the event that starts one, and a campaign is a legacy, linear automation feature that HighLevel has deprecated. For anything you build today, you build a workflow.

The confusion comes from the words, not the ideas. "Trigger" means two different things in GoHighLevel: the first block inside a workflow, and an older standalone object that existed separately from workflows. "Campaign" is the old feature that standalone triggers fed contacts into. Tutorials written before the change use all three terms as if they were peers, which is why searchers land on this question.

The rest of this guide takes each in turn, then covers the case that actually costs people money: an account that still has a campaign and a workflow both reacting to the same event. Everything about HighLevel's own behavior below comes from its support portal, and we name the article each time so you can check it. Product behavior changes, so treat this as accurate at the time of writing.

What is a workflow in GoHighLevel?

A workflow is a visual automation in GoHighLevel that starts when a trigger fires, then runs actions such as sending messages, updating contacts, or moving opportunities, and can split contacts into different paths with if/else conditions.

HighLevel's Getting Started with Workflows article describes the parts plainly: triggers start the workflow, optional filters narrow when it runs, and actions are the steps that follow. You can add more than one trigger to a single workflow, so contacts can enter from different sources. Its execution history shows skipped steps, failed actions, and error messages, which is the first place we look when someone says a workflow "did nothing."

Our GoHighLevel setup page covers how we design entry, exit, and re-entry so these blocks do not fight each other, and our setup order guide covers what to build first.

What is a trigger in GoHighLevel?

A trigger is the event that starts a workflow, for example a form submitted, a tag added, a pipeline stage changed, an appointment status update, or data received on an inbound webhook.

HighLevel's own introduction to workflows calls a trigger the "if" in the automation and the action the "then." That framing is worth keeping. A trigger does nothing alone: it only says when a contact enters. What happens after that is decided by the workflow's actions, filters, and branches.

The second meaning is the trap. Before the platform moved to workflows, a standalone Trigger object existed on its own and placed contacts into a campaign. HighLevel's article on workflows vs campaigns and triggers says that campaigns and triggers are the deprecated features. The trigger block you drop into a workflow today is a different, current thing that happens to share a name.

What are the most common GoHighLevel workflow triggers?

The triggers most builds start from are Form Submitted, Contact Tag, Pipeline Stage Changed, Appointment Status, Customer Replied, Contact Changed, Call Details, and Inbound Webhook.

These names and descriptions come from HighLevel's list of workflow triggers, which is much longer than this table and grouped by category (Contact, Events, Appointments, Opportunities, Payments and more).

When a workflow never fires, the trigger is the first suspect. In accounts we look at, the cause is usually a filter that is narrower than the person who built it remembers, or a tag that is added by a different automation a few seconds too late. Our GoHighLevel expert page has the fuller checklist for accounts that are already live.

What is a campaign in GoHighLevel?

A campaign is a legacy GoHighLevel feature that ran a sequence of steps for contacts enrolled in it, and HighLevel now lists it as deprecated in favor of workflows.

In the old model, a standalone trigger, or a manual add, placed a contact into a campaign, and the campaign ran its timed steps in order. HighLevel's own comparison says workflows can use if/else conditions and filtering for more personalized automation, combine what triggers and campaigns did separately, keep an execution log for troubleshooting, and are easier to test. Those are the four gaps that matter, and each one is something a campaign builder had to work around.

The practical description we use with clients: a campaign is a conveyor belt, and a workflow is a decision tree. A conveyor belt is fine until the item on it needs to be pulled off because something changed.

Are GoHighLevel campaigns and triggers deprecated?

Yes. HighLevel states that campaigns and triggers are deprecated, that new campaigns and triggers could no longer be created after April 15, 2024, and that users should migrate existing campaigns to workflows.

Two HighLevel support articles carry the detail. In Workflows vs Campaigns/Triggers (Deprecated features), HighLevel says agencies created after November 2021 do not see the deprecated features at all, and that older sub-accounts only show them when they were created from a snapshot that already contained campaigns and triggers. In Campaigns are no longer maintained, it gives April 15, 2024 as the date after which you could no longer create them or get support, and says the Campaigns and Triggers tab is not shown in the CRM.

Two things we could not confirm from HighLevel's documentation, so we will not state them as fact. The first is a removal date: neither article gives one. The second is exactly how an already-existing campaign behaves in your account today, because that depends on your account's history and can change. If you have campaigns you did not build, look at them in your own account rather than assuming.

This also explains why some agencies never see a campaign and others still find several. It comes down to which snapshot the sub-account was cloned from, not to anything you did.

What is the actual difference between a workflow and a campaign?

A workflow can branch on conditions, filter who enters, and log what it did, while a campaign is a deprecated sequence feature that HighLevel no longer supports. Workflows also absorb the trigger role that used to be a separate object.

We kept this table to what HighLevel itself documents. Blog posts elsewhere list many more differences, and some of them are plausible, but if a claim is not in the support portal we would rather leave it out than repeat a guess.

When should you use a workflow instead of a campaign?

Use a workflow whenever the automation should change course based on what a contact does, which covers appointment reminders, lead follow-up, no-show recovery, and almost every other real sequence. Today that also means every new build.

Take a booking follow-up. A lead fills out a form and you want a text now, an email tomorrow, and a call task on day three. The moment the lead books, all of that should stop. In a workflow you add a Wait step that holds for a reply or a booking with a timeout, then an If/Else that checks the outcome: booked contacts exit, replied contacts move to a human, silent contacts continue. HighLevel's Wait action supports holding for a contact reply, for a contact action such as a click, for an appointment-relative time, or for a custom condition, and most types take an optional timeout.

For the "stop when they book" case there is also the Goal Event action. When a contact meets the goal, HighLevel moves them straight to the goal step wherever they were in the workflow, and you choose whether the workflow ends, continues, or waits.

Two workflow settings matter as much as the branches. Stop on Response ends the workflow for a contact who replies to a message sent from that workflow. Allow Re-entry decides whether a contact who finished or was removed can enter again, with an exception: HighLevel says appointment and invoice-based triggers always allow multiple entries. Both are documented in Workflow Settings Overview, and both are on the list of things we check in every audit.

When is a standalone trigger still the right tool?

For a new build, never. The trigger you use going forward is the one inside a workflow, and the standalone object belongs to the deprecated system.

The only reason to touch a standalone trigger is that an account already has one. In that case do not delete it on sight. Open it, note which campaign it feeds and what that campaign sends, and check whether a newer workflow reacts to the same event. Removing a trigger that is still doing real work can quietly stop a reminder or a follow-up someone is relying on, and nobody will see an error.

What happens if you still have a campaign and a workflow on the same event?

A contact can receive both automations' messages, because nothing coordinates them. That double messaging is the most common symptom of a leftover campaign, and the fix is to decide which one owns the event and retire the other.

The pattern we look for when we audit an inherited account is a legacy campaign wired to an old trigger, plus a newer workflow that someone built later for the same event without knowing the campaign existed. Neither builder is around any more, and the leads see the result: two texts, two emails, sometimes contradicting each other. The signs are easy to check for:

• A contact's conversation shows near-duplicate messages within minutes of one event.
• The Campaigns and Triggers area exists in the sub-account (if it is hidden, this particular problem cannot come from a campaign).
• Two automations share the same trigger event and nobody can name the owner of each.

Our guide to fixing a messy GoHighLevel account covers the wider cleanup order, including why you disable one automation at a time instead of deleting several at once.

How do you migrate an old campaign into a workflow?

Use HighLevel's import to create a workflow from the campaign, then rebuild the logic the campaign lacked, test every path, and only then turn the old campaign and its standalone trigger off. Leaving both running is a classic cause of duplicate messages.

HighLevel's deprecation article says you can import your campaigns into workflows and then add triggers to them. An import gives you a starting point, not a finished automation. It copies the linear steps, which means the linear limitations too. Here is the order we follow:

1. List what the campaign does now: every step, every wait, and what currently enrolls contacts into it.
2. Decide whether it is one job or several stitched together. If several, plan one workflow per job.
3. Import it into a workflow, and read the imported result rather than trusting it. Confirm the timings and message content came across as expected.
4. Add a trigger and filters, then the branches the campaign never had: stop on a reply, exit on booking, separate path for no-show.
5. Set re-entry deliberately, and set the time window and timezone so messages do not go out at 3 a.m.
6. Run test contacts through every path, including the path where nothing happens, before anything goes live.
7. Publish the workflow, watch its execution history for a few days, and only then turn off the old campaign and standalone trigger.

Do not turn the old campaign off and the new workflow on in the same minute. If you do, and something is wrong, you will not know which of the two caused it. Agencies that cloned many sub-accounts from one snapshot should also fix the snapshot first, or the same old campaign keeps arriving in new accounts. Our GoHighLevel automation for agencies page explains how we handle that.

What are the most common mistakes with workflows, triggers, and campaigns?

The most common mistakes are leaving an old campaign live next to its replacement, building a trigger too broad or too narrow, and never setting re-entry on purpose. Each one produces the same complaint: contacts get messages they should not.

• Leaving the old campaign live after building the workflow. Two automations, one event, double messages.
• Triggers that are too broad. Contacts enter who should not, because no filter narrows the trigger.
• Triggers that are too narrow. A filter is so specific that almost nobody qualifies, and the workflow looks broken when it is only quiet.
• Re-entry left at its default. A contact who already went through the workflow is pulled back in by an unrelated change, or is blocked from a legitimate second pass.
• No stop condition. Nothing removes a contact who replied or booked, so follow-up keeps going. Stop on Response and a Goal Event exist for exactly this.
• Trusting the name. A workflow called "New Lead Follow-Up v2" tells you nothing about its trigger or whether it is published. Read the trigger and the execution history.

The mistake we would rank first is the one that gives this guide its title: reaching for a campaign, or a campaign-shaped straight-line workflow, for a process that has decisions in it. If the sequence must ever stop, branch, or react to a reply, it needs conditions from the start.

When is a workflow the wrong choice?

A workflow is the wrong tool when the logic is heavy on data lookups, loops, or several outside systems, and it is not worth migrating an old campaign that works and causes no problems.

Two honest limits. First, a legacy campaign that still does one simple linear job correctly, with no duplicate messages and no missing stop condition, does not need to be rebuilt this week. Migrate the ones causing problems first, and put the rest on a list. Second, workflows are strong inside GoHighLevel, but automations that need to loop through records, run a lot of custom logic, or coordinate several systems are often easier to run in a tool like n8n, with GoHighLevel calling it by webhook. We would not build a fifty-step workflow with nested branches when a small workflow plus an n8n flow is easier to read and easier to debug.

A third limit is documentation. HighLevel changes its workflow builder often, and features get renamed or moved. Check the support article for the exact action before you build around it, and do not rely on an old tutorial's screenshots.

Workflows vs triggers vs campaigns: which one do you need?

Build a workflow, start it with the trigger that fits the event, and add branches wherever the outcome depends on what the contact does. Campaigns and standalone triggers only matter to accounts that already have them.

If you are not sure what your account is running, a GoHighLevel account audit will list every campaign, trigger, and workflow and tell you which need attention. If you are starting fresh and want it built on workflows from day one, see our GoHighLevel setup service. For pricing context, our GoHighLevel pricing guide covers what the platform itself costs.

For a workflow in production, our dental CRM case study reports a patient-intake build where first response time fell from 45 to 90 minutes to under 5 minutes in the first weeks, and our real estate case study shows the same approach for lead follow-up. Both figures are reported by Autoesta on those pages, and the case study index lists the rest. If you want a second opinion on who should do the work, read what makes a real GoHighLevel expert.

Overlapping triggers are one reason follow-up sequences misfire.

Once you know the pieces, see what GoHighLevel automation does well and what still needs a person.

More questions about GoHighLevel workflows, triggers, and campaigns

Can workflows and campaigns run at the same time in one account?

If both exist and both react to the same event, both can message the contact, which is the double-messaging problem above. Decide which one owns the event and turn the other off.

Will GoHighLevel remove campaigns entirely?

HighLevel's support articles do not give a removal date at the time of writing. They do say creation of new campaigns and triggers ended on April 15, 2024, so building new automation on them works against the platform's stated direction.

Do I need to rebuild every old campaign right away?

No. Start with the ones causing problems, such as duplicate messages or missing stop conditions. A simple one that still does its job can wait, though it is worth listing so it does not become an unowned surprise later.

Is a workflow's trigger the same thing as the old standalone Trigger?

No. The trigger inside a workflow is a current part of the builder. The standalone Trigger was a separate object that fed contacts into a campaign, and HighLevel lists it among the deprecated features.

How do I tell if my account still has campaigns?

Look for the Campaigns and Triggers area in the sub-account. HighLevel says the deprecated features are visible only in accounts created from older snapshots that contain them, and that you enable them from the Business Profile settings in that case. If you find some, open each one and check its enrollment before touching it.

Can Autoesta migrate my old campaigns to workflows?

Yes. We map what each campaign and trigger does, rebuild the ones still in use as workflows with the branching they lacked, and confirm nothing is double-messaging before we call it done. Book a free 30-minute strategy call or tell us what you are running today, and we will tell you what to migrate first. Our audits are free, and a small automation build of two or three automations from about $1,000.

See these building blocks applied in lead follow-up that converts and sales pipeline automation.