A pipeline automation is bound tighter to its pipeline and stages than almost any other workflow type, which is exactly why a raw copy lands in a new account pointing at nothing. Here is how to move one so the pipeline and every stage are remapped by name.
A pipeline automation is one of the most useful things you can build in GoHighLevel — and one of the most account-specific. It watches opportunities as they move through a pipeline and reacts to each stage: send a follow-up when a deal reaches "Proposal Sent", assign an owner at "Negotiation", notify the team when it lands in "Won". That tight binding to a particular pipeline and its stages is what makes it powerful in one account and fragile the moment you try to move it to another. This guide explains why that happens, and how to copy the automation so the pipeline and stages are rewired to the destination rather than left dangling.
A pipeline automation is simply a workflow whose trigger or actions depend on where an opportunity sits in a pipeline. The common shapes are a trigger that fires on Opportunity Stage Changed or Opportunity Status Changed, and actions that create or move an opportunity into a specific stage. Around those sit the usual pieces — waits, if/else branches, notifications, tasks — but the part that defines the type is the dependence on one named pipeline and its ordered stages.
Captured faithfully, that is a genuinely valuable build: a repeatable sales or onboarding sequence that keeps every opportunity moving without anyone remembering to nudge it. ExportGHL captures the whole thing — every trigger, every action in order, waits, branches and settings — the same way it treats any other workflow type. There is nothing pipeline-specific about how it is saved; the difference shows up only in what has to be remapped on the way into a new account.
A workflow is not a self-contained document. When a step says "move to Proposal Sent", GoHighLevel does not store the words "Proposal Sent" — it stores an id that points at that exact stage, inside that exact pipeline, in the account where the workflow was built. The pipeline itself is stored as an id too.
Drop that raw workflow into a second account and both ids point at nothing. The destination has its own pipelines and its own stages, each with completely different ids, even when the names are identical. The copied automation still has the right shape in the editor, but its trigger is listening for a stage that does not exist there and its actions are trying to move opportunities into stages the account has never heard of. In practice the steps fail silently: opportunities never move, the trigger never fires, and nothing in the builder tells you the workflow is quietly broken. This is the gap ExportGHL Workflows is built to close.
Every workflow type carries account-scoped references, but a pipeline automation leans on the two that are hardest to get right. In rough order of how much this type depends on them:
Because stages carry so much of the weight here, this type is a good stress test for name-based remapping. Get the pipeline and stage names lined up and most of the work is done; the rest is the same supporting-reference handling every workflow needs.
ExportGHL treats the copy as three steps — save once, a free readiness check, then deploy — so the same saved automation can be dropped into each account you manage without rebuilding it.
On a cross-account deploy, remap runs automatically: ExportGHL reads every account-scoped reference in the automation and matches it to a record with the same name in the destination. For a pipeline automation it does this in two layers: first it finds the destination pipeline whose name matches the source pipeline, then it matches each stage inside it by name and rewrites those ids too. A trigger watching "Proposal Sent" ends up watching the destination's own "Proposal Sent"; an action that moves a deal to "Won" is rewired to the destination's "Won".
The supporting references — tags, users, custom fields, email templates — are matched by name in the same pass. The full logic, including how ties and near-matches are handled, is covered in the cross-account id remap guide, and the end-to-end move for any workflow type is in copy a workflow between accounts.
Name matching is only as good as the names, and stages are where mismatches usually hide. Pipelines drift between accounts — a stage renamed from "Proposal Sent" to "Quote Sent", an extra "Follow-up" stage added, a different capitalisation. Each stage the remap cannot match by name is flagged rather than guessed, and if any references are still unmapped the automation is deployed as a draft instead of being published broken.
A draft never runs. You open it, see exactly which stages or supporting references need attention, either point each step at the right destination record or create the missing one, and publish when it is genuinely ready. The cleanest result comes from a quick pass before you deploy: make sure the destination pipeline exists and its stages are spelled the way the source spells them. Or flip on the opt-in auto-create toggle and ExportGHL builds any missing pipeline — with its stages — and missing tags for you in the destination, leaving only templates, calendars and users to set up by hand. If tags or custom fields are the ones coming up unmapped, see tags and custom fields not mapping for how to close those gaps.
No credit card. Save it once, then deploy it into any account with the pipeline and every stage remapped for you.
Start free
ExportGHL