You copied a workflow into another account, switched it on, and new contacts never enrol. Nothing errors — it just sits there. Here are the checks that catch the cause fastest, and how to deploy so the trigger lands wired to the right records.
You copied a workflow into a new GoHighLevel account, switched it on, and nothing happens. New contacts arrive, match what the trigger should catch, and never enrol — nothing errors, nothing lands in the history. This is the single most common complaint after a workflow moves between accounts, and it almost always comes down to the trigger: the one part of a workflow that depends entirely on how the destination account is set up, which a raw copy carries none of. This guide walks the checks in the order that catches the most failures first, then shows how a cross-account deploy wires the trigger to real records instead of dead ids.
A workflow has two halves that fail differently. The actions — send an email, add a tag, move an opportunity — only run once a contact is already inside. The trigger is what puts a contact inside in the first place, and it is the part most likely to be quietly broken after a copy.
That is because a trigger is a filter, and a filter points at records specific to the account it was built in. A trigger that reads "Contact tag added: booked-call" is not looking for the word booked-call — it is looking for a tag id, and that id only exists in the source account. "Opportunity status changed in the New Leads pipeline" points at a pipeline id, a form trigger at a form id. Drop those into another account and the ids reference nothing, so no incoming contact matches and the workflow never fires. The actions downstream are fine — the door into the workflow is simply bricked up.
Before anything else, rule out the thing that catches most people: the publish state. Any workflow that arrives from a copy, a snapshot, or GoHighLevel's own cross-account tooling lands switched off — as a draft — so it cannot run before you have checked it. A draft enrols nobody, however perfect its trigger is.
Open the workflow in the destination account and look at the toggle in the top right; if it says Draft, flip it to Publish. Then confirm the trigger itself has not been left inactive — a workflow can be published while an individual trigger inside it is switched off, and both have to be on before a single contact can enter. If your copied workflow does nothing at all, this is the first thing to check, and often the only thing wrong.
If the workflow is published and still dead, the trigger is almost certainly filtering on a record the destination account does not have — or has under a different id. The usual culprits:
In every case the symptom is the same, and the symptom is nothing: the workflow is live, contacts arrive, and none match, because what the trigger watches for does not exist here. GoHighLevel will not warn you: the trigger looks complete in the builder, often still showing the original record's name, while underneath it points at an id that resolves to nothing.
Do not test a trigger on a contact already in the account — re-entry rules and existing enrolment history muddy the result. Create a brand-new test contact and make it match the trigger cleanly.
A fresh, unambiguously matching contact is the fastest way to tell a trigger problem from an action problem: if the contact enrols but later steps misbehave, that is an action pointing at a missing record, not the trigger.
The manual fix works, but you repeat it for every trigger in every account you copy into, and it is easy to miss one. Deploying with ExportGHL Workflows instead of a raw copy rewrites the trigger's references for you as part of the import.
Cross-account remap runs automatically on a cross-account deploy: ExportGHL reads every account-scoped reference in the workflow — including the ones inside triggers and filters — and matches each by name against the destination. The tag named booked-call is matched to the destination's booked-call tag and its id substituted; pipelines and stages, forms, users, calendars and custom fields are rematched the same way. The trigger that arrives is already looking at records that exist here, so a matching contact enrols on the first try. The deeper version is in the cross-account remap guide, and the full move is covered in copy between accounts.
Remap cannot invent a record that is not there. If the destination has no tag, form or stage with a matching name, ExportGHL does not guess or point the trigger at the nearest thing — it flags the unmatched reference and imports the workflow as a draft rather than publishing it.
That is deliberate, and it is the opposite failure mode to a raw copy. A raw copy goes live with dead references and fires on nobody. A remapped import that could not resolve everything stays a draft and tells you exactly which reference needs attention: you create or rename the missing record, point the flagged item at it, and publish when it is ready. The worst case is a minute of cleanup on a draft — never an automation switched on and silently enrolling no one. If you only copy within one account the records already exist and this rarely bites — see clone a workflow for that simpler case.
No credit card. Deploy across accounts and remap lands the trigger wired to the destination's own records — or as a draft, never broken-and-live.
Start free
ExportGHL