Triggers in HighLevel (Legacy)

Updated: February 6, 2026  | 
Author: Bill Stilwell

This post covers what Triggers were, how they worked alongside Campaigns, how they compare to Workflow Builder, whether to migrate existing setups, and the step-by-step process for transitioning legacy Trigger automations to Workflow Builder.

Reading time: about 5 minutes.

What Are Triggers in HighLevel?

Triggers in HighLevel were the original automation mechanism – predating the current Workflow Builder system. A Trigger was a simple rule: when a specific event happens, fire a Campaign.

The event side was the trigger; the Campaign was the action.

For example: when a contact submits a specific form (the event), fire the “New Lead Follow-Up” campaign (the action). The campaign then sends a sequence of SMS and email messages on a pre-configured schedule.

This Trigger-and-Campaign architecture was HighLevel’s first approach to automation. It was functional but limited compared to Workflow Builder – the multi-step canvas that replaced it as HighLevel’s primary automation tool.

How Triggers and Campaigns Worked Together

In the legacy system, Triggers and Campaigns were separate objects that worked as a pair. A Campaign was a standalone message sequence – a series of SMS and email messages with timing delays between them.

The Campaign sat dormant until something fired it.

A Trigger was the firing mechanism. It watched for a specific event in the sub-account.

When the event occurred – a form submission, a tag being applied, an appointment being created – the Trigger activated the associated Campaign for the contact who triggered the event. The Campaign then started sending its message sequence to that contact.

The separation of Trigger and Campaign made the system less intuitive than Workflow Builder. To understand what automation a contact would receive, you had to look up which Campaign the Trigger was firing and then examine the Campaign separately.

In Workflow Builder, the trigger and all action steps are visible in a single canvas.

What Events Triggers Could Respond To

Legacy Triggers in HighLevel could respond to events including: contact created (when a new contact enters the sub-account), form submitted (when a specific form was completed), appointment scheduled (when a new appointment was created), appointment status changed (when an appointment was marked as showed, no-showed, etc.), tag added (when a specific tag was applied to a contact), opportunity stage changed (when a contact’s pipeline stage moved), and a few other contact-level events.

These same events are available as triggers in Workflow Builder – plus many additional trigger types that were not available in the legacy system. Every event a Trigger could respond to can be replicated in Workflow Builder.

The migration path always exists for any legacy Trigger setup.

Triggers vs. Workflow Builder

The core difference between the legacy Trigger system and Workflow Builder is depth and flexibility.

The legacy Trigger system was two steps: event fires Campaign. The Campaign ran its sequence linearly.

There was no branching, no conditions, no ability to add non-message actions (like applying a tag or creating a task), and no visibility into the automation flow in a single interface.

Workflow Builder is a multi-step canvas where every element – the trigger, wait actions, conditional branches, message actions, tag actions, task creation, pipeline movement, and more – is visible and configurable in a single interface. Workflow Builder can replicate anything a Trigger-and-Campaign pair could do, and then significantly extend the automation logic beyond what was possible in the legacy system.

There is no automation use case that requires the legacy Trigger system over Workflow Builder. Workflow Builder is strictly more capable.

The only reason to maintain a legacy Trigger is if it is currently running correctly and the migration effort has not yet been prioritized.

Are Triggers Still Active?

Yes. Trigger-based automations set up before Workflow Builder became the standard continue to function in sub-accounts where they were configured.

HighLevel did not forcibly migrate all Triggers to Workflow Builder – existing setups continue to run.

However, Triggers are not receiving new features or improvements. The platform’s automation development effort is entirely focused on Workflow Builder.

Triggers are in maintenance mode – they work as configured but do not get better.

In newer sub-accounts – particularly those onboarded after Workflow Builder became the default – Triggers may not be visible in the navigation or may be unavailable. The Trigger section is a legacy interface that may be visible or hidden depending on the sub-account’s configuration and age.

When to Migrate

The practical guidance on migration timing: migrate a legacy Trigger when it needs to be changed, updated, or improved – not necessarily all at once as a project. A Trigger-based automation that is running correctly and does not need changes can stay as-is until a natural update opportunity arises.

But if an automation needs a new message, a timing change, or any improvement, rebuild it in Workflow Builder rather than editing the legacy Trigger-and-Campaign pair.

Any new automation the sub-account needs should always be built in Workflow Builder – never in the legacy Trigger system. Agencies onboarding new clients and using snapshots should ensure their snapshot templates use Workflow Builder automations, not legacy Triggers.

If a sub-account has active Triggers powering critical business automations, scheduling a dedicated migration – working through each Trigger-and-Campaign pair methodically – ensures the sub-account’s automation is on the current, maintained system before any Trigger stops working unexpectedly.

The Migration Process

Migrating a Trigger to Workflow Builder follows a consistent process regardless of the specific automation being moved.

First, document the existing Trigger – what event it responds to, any filter conditions applied, and which Campaign it fires. Then document the Campaign – what messages it contains, in what order, with what timing delays between each message.

In Workflow Builder, create a new workflow. Set the trigger to the equivalent event.

Add Wait actions replicating the Campaign’s timing delays. Add SMS or Email actions replicating the Campaign’s messages – copying the message content.

If the messages use merge tags, verify the merge tag syntax is correct for Workflow Builder (which may differ slightly from the legacy Campaign format).

Test the new workflow with a test contact. Verify each message sends correctly at the right time.

Activate the workflow. After confirming it runs as expected, deactivate the legacy Trigger.

The automation is now fully in Workflow Builder.

What Can You Do With It?

• Understand legacy automation setups in older HighLevel sub-accounts: If a sub-account was built before Workflow Builder, its automation may be entirely in Triggers and Campaigns. Understanding how these work is necessary for auditing, maintaining, or migrating those setups.
• Identify automation gaps caused by legacy Trigger limitations: Legacy Triggers cannot add tags, create tasks, update pipeline stages, or branch conditionally. Migrating to Workflow Builder fills all those gaps without rebuilding the core message logic from scratch.
• Migrate systematically to Workflow Builder without disrupting active automations: The migration process runs the new workflow in parallel before deactivating the Trigger – ensuring no gap in automation coverage during the transition.
• Ensure snapshots use current automation infrastructure: Snapshots that contain legacy Trigger automations pass that legacy architecture to every sub-account they are deployed to. Rebuilding snapshot automations in Workflow Builder ensures new clients start on the current system.

Key Definitions

Who Is This For?

How to Migrate Triggers to Workflow Builder

Step 1: Find the Triggers section

Navigate to the Triggers section in the sub-account (often under Automation or directly in the sidebar). List all active Triggers.

Step 2: Document each Trigger

For each active Trigger, note: the trigger event, any filter conditions, and the Campaign it fires.

Step 3: Document each associated Campaign

Open each Campaign the Triggers reference. Document the full message sequence – each message, its content, and its timing delay from the previous step.

Step 4: Create the equivalent Workflow

In Workflow Builder, create a new workflow. Set the trigger to the equivalent event.

Add Wait actions with the Campaign’s timing delays. Add SMS and Email actions with the Campaign’s message content.

Step 5: Enhance beyond the legacy logic

While building, add capabilities the legacy system did not support – tag additions, task creation, pipeline stage updates, If/Else branches based on contact behavior. Make the migration an improvement, not just an equivalent.

Step 6: Test the new workflow

Test with a test contact. Verify each step fires correctly.

Step 7: Activate the new workflow

Activate the workflow. It now runs alongside the legacy Trigger – both fire for qualifying events temporarily.

Step 8: Deactivate the legacy Trigger

After confirming the workflow runs correctly, deactivate the legacy Trigger. The automation now runs entirely through Workflow Builder.

Step 9: Repeat for remaining Triggers

Work through the full Trigger inventory, migrating each one. Prioritize the most critical and highest-volume automations first.

How Does It Connect to HighLevel?

• Workflow Builder: Workflow Builder is the direct replacement for the legacy Trigger system. Everything a Trigger could do, Workflow Builder can do – plus far more. All new automation and all migrated Triggers end up in Workflow Builder.
• Email Campaign Automation: Email Campaign Automation is the current-system equivalent of what legacy Campaigns handled for email. Note: legacy “Campaigns” (the message sequences fired by Triggers) are different from the current Email Campaign Automation feature – they share a name but are different systems.
• Tag-Based Automation: Tag-Based Automation in Workflow Builder replicates and extends one of the most common legacy Trigger event types – tag added. The Workflow Builder Tag Added trigger is the modern equivalent of the legacy Tag Added trigger.
• Contact Management: Legacy Triggers responded to contact-level events – contact created, form submitted, tag added. These same events are available as Workflow Builder triggers. Contact Management is where the contacts that triggered legacy automations are stored and managed.
• Snapshot Manager: Snapshots that were created from older sub-accounts may contain legacy Trigger automations. When deployed to new sub-accounts, those legacy Triggers deploy too. Updating snapshots to use Workflow Builder automations instead is important for new client onboarding.

Common Questions

What are Triggers in HighLevel?

The legacy automation system – event-based rules that fired Campaign message sequences when specific events occurred. Superseded by Workflow Builder as the primary automation tool.

Are Triggers still used in HighLevel?

They still function in older sub-accounts where they were configured. They are not the recommended approach for new automation.

Workflow Builder is the current system for all new and migrated automations.

What is the difference between Triggers and Workflow Builder in HighLevel?

Triggers were a two-part system: event fires Campaign. Workflow Builder is a multi-step canvas combining trigger, conditions, wait times, multiple action types, and branching in a single interface.

Workflow Builder is strictly more capable.

Should I migrate from Triggers to Workflow Builder in HighLevel?

Yes, for any active automation that needs changes. Rebuild in Workflow Builder rather than editing the legacy Trigger.

New automations should always be in Workflow Builder.

Where do I find Triggers in HighLevel?

Under Automation or in the sidebar as a legacy section. In newer accounts, Triggers may not be visible – only Workflow Builder is available.

In older accounts, both may appear.

What events could Triggers respond to in HighLevel?

Contact created, form submitted, appointment scheduled, appointment status changed, tag added, opportunity stage changed – the same events available as Workflow Builder triggers, plus additional trigger types only Workflow Builder supports.

To Wrap It Up

The legacy Trigger system was HighLevel’s original approach to automation – functional, but limited compared to what Workflow Builder now offers. If a sub-account still has active Triggers powering its automations, those automations work – but they cannot grow, branch, or improve without migrating to Workflow Builder.

The migration is not urgent for automations that are working correctly and not in need of changes. It is urgent for any automation that needs improvement – because the improvement will be built in Workflow Builder anyway, and it is more efficient to fully migrate than to maintain both systems simultaneously.

The simplest rule: never build new automation in the legacy Trigger system. Always use Workflow Builder.

When a legacy Trigger needs an update, migrate it fully as part of that update rather than modifying it in place. Over time, this approach naturally transitions the entire sub-account to Workflow Builder without a dedicated migration project.

1. Navigate to the Triggers section and audit all active Triggers
2. For each active Trigger, document the event and the associated Campaign
3. For each active Campaign, document the full message sequence and timing
4. Prioritize the most critical automations for first migration
5. Build the first equivalent workflow in Workflow Builder
6. Test, activate the new workflow, confirm it runs correctly
7. Deactivate the legacy Trigger
8. Repeat for remaining Triggers in priority order
9. Ensure any snapshot templates are updated to use Workflow Builder automations only

When migrating, rebuild the automation better – not just equivalent. The migration is the opportunity to add the features the legacy system could not support: tag actions when a contact completes a sequence, task creation for human follow-up at key points, If/Else branching for contacts who reply versus those who do not.

The effort of migration is the same whether the new workflow is equivalent or improved. Build the improved version.