Cross-Account Workflow ID Remap in GoHighLevel (Pipelines, Tags, Users, Fields)

Why a workflow is tied to the account it was built in

Inside GoHighLevel, almost everything a workflow touches is a record with its own internal id: a pipeline, a stage within that pipeline, a user you assign a task to, a tag, a custom field, a calendar, a template. When you build a workflow, GoHighLevel does not save the names of those records in the workflow definition. It saves their ids. An "Add tag: Hot Lead" action does not store the text "Hot Lead" — it stores something like tag_7c1f…, the id of that tag in that account.

Those ids are account-scoped. The same tag, created by hand in a second account, gets a completely different id there. So when a workflow definition is lifted out of one account and dropped into another, every id it carries still points at records that live only in the source account. The destination has no record with that id, so the reference dangles. This is the root cause of nearly every "I copied my workflow and it stopped working" report, and it is why a raw copy of the JSON is not a real move.

Exactly which fields break

The breakage is not random — it is every field in the workflow that holds an account-scoped id rather than a literal value. In practice that means:

• Pipeline and stage. "Create / update opportunity" and "move to stage" actions reference a pipeline id and a stage id inside it. Both are account-specific, and the stage id is meaningless without its parent pipeline.
• User / assignee. "Assign to user" and round-robin steps reference user ids. The same person has a different id in each account, and may not be a member of the destination at all.
• Tags. Add-tag and remove-tag actions, and any tag-based trigger or if/else branch, all run on tag ids.
• Custom fields. Anything that reads or writes a custom field — including conditions that branch on a field's value — points at the field's id.
• Calendars. Appointment and booking actions reference a calendar id.
• Email and SMS templates. "Send email" or "send SMS" steps that use a saved template reference that template's id.
• Custom values. Merge fields and account-level custom values are resolved by id and are not portable on their own.
• Workflow-to-workflow references. "Go to another workflow" or "remove from workflow" steps point at the id of a sibling workflow — which must itself have been moved and remapped, or there is nothing to point at.

Each one of these is a quiet failure point. GoHighLevel will often let you save a workflow with a dangling reference; it just does nothing, or does the wrong thing, when a contact hits that step in production. That is the worst kind of break — invisible until a live contact runs through it.

How ExportGHL matches by name and rewrites the ids

ExportGHL Workflows treats the move as a reconciliation, not a copy. When you deploy a saved workflow into a destination account, it reads every account-scoped reference in the definition, looks up what that reference was in the source (its name), and finds the record with the matching name in the destination. The dangling source id is then rewritten to the destination's own id for that pipeline, stage, tag, user, field, calendar or template.

Matching by name is the right key because names are what the two accounts actually share. You rarely have the same internal ids across accounts, but you very often have a "Hot Lead" tag, a "Sales Pipeline" with a "Booked" stage, and a "Lead Source" custom field in both. ExportGHL walks the full reference graph — including stages nested inside their pipeline and workflow-to-workflow links — so a remapped stage lands in the correct remapped pipeline, not just any stage with a similar name.

Because it deploys into the destination as a new workflow, nothing you already have is overwritten. (You can choose to update an existing one, but that is an explicit choice, not the default.) The result is a workflow that references the destination's real records and runs the same way it did in the source. This page is part of the complete guide to exporting GoHighLevel workflows, the hub for saving, moving and backing up automations across accounts.

What ExportGHL remaps, preserves, and drafts

It helps to separate the two kinds of thing inside a workflow: the account-scoped references that have to be remapped, and the structural building blocks that carry across on their own.

References remapped by name. Each of these is matched to the destination's own record and the id is rewritten. If a match exists it is preserved; if none exists the workflow is left as a draft until you supply or map it:

• Pipelines
• Stages (inside their parent pipeline)
• Tags
• Users and assignees
• Custom fields
• Calendars
• Email and SMS templates

Workflow building blocks. The structure of the automation is preserved exactly, because it is not account-scoped. A building block is only ever drafted on account of an account-scoped reference it points at — never because of the block itself:

• Triggers
• Trigger and action filters
• Actions, in order
• Wait steps and timers
• If/else branches
• Goals

In short: structure and literal values (wait times, plain message text, branch logic) are preserved intact, every account-scoped reference is remapped by name where it matches, and anything unmatched holds the whole workflow in draft rather than publishing it broken.

What happens when a reference cannot be mapped

Sometimes a name genuinely does not exist in the destination — the "Hot Lead" tag was never created there, or a user is not a member. ExportGHL does not guess, and it does not publish something that will fail silently. It flags every unmatched reference so you can see precisely what is missing, and it keeps the deployed workflow as a draft. You then create the missing record (or map the action to an existing one) and publish when everything resolves.

This draft-by-default behaviour is deliberate. The failure mode you are avoiding is a workflow that looks live but quietly mis-fires, so the safe move is to refuse to publish until every reference points at something real.

Why JSON-only competitors leave these broken

Tools such as GHL Workflows Pro, GHL Workflow Importer/Exporter and GHL Workflows JSON Exporter can export a workflow's JSON and import it into another account. (Super Cloner is sometimes grouped with them, but it clones funnel and website pages, not workflows.) That moves the structure, but the ids inside it are copied verbatim — they are not reconciled against the destination. So the pipeline, tag, user, field and template references still point at the source account's ids, and you are back to repairing every step by hand. Exporting the JSON is the easy 80%; remapping the account-scoped references is the hard 20% that actually makes the workflow run, and it is the part they skip. If you are weighing options, the cloner comparison lays the behaviour out side by side, and the step-by-step for a single move is in copy between accounts.

GoHighLevel's own tooling does not close this gap either. Native duplication only works within one account, and snapshots copy a whole-account template — they resolve references only because the snapshot brings its own copies of every pipeline, tag and field, which is no help when you are moving one workflow into an account that is already live. Cross-account remapping exists specifically for the case GoHighLevel leaves uncovered.

Try it on a real workflow first

The free trial moves one workflow end to end so you can see the remap and the draft-flagging on your own account before spending anything. After that it is pay-as-you-go credits that never expire, or a one-time Toolkit licence with no subscription — the pricing page has the detail.

Frequently asked questions