Tags & Custom Fields Not Mapping After a GoHighLevel Workflow Copy?

When a workflow lands in a new account with its tags and custom fields blank, the instinct is to assume the copy failed. It did not. The workflow definition arrived intact, and what did not arrive is any of the objects those steps were pointing at. That gap is predictable once you know how GoHighLevel stores what a workflow references, and the cause points straight at the fix.

Why tags and custom fields go blank across accounts

A GoHighLevel workflow is a sequence of steps, and each step that touches a tag, a custom field, a pipeline stage, a user or a calendar carries a reference to that specific object. When you copy the workflow into a different sub-account, the steps copy faithfully but the objects they point at are left behind in the source account. The destination has no record that answers to those references, so the dropdowns that should show "Hot Lead" or "Lead Source" come up empty.

This is why the symptom is so consistent: the workflow "imported fine", the layout looks right, and yet the tag, field and pipeline selectors are blank or greyed out. Nothing is corrupted. The account-scoped references simply have nothing to resolve against in the new account.

Ids vs names: what a workflow actually stores

The key fact is that a workflow does not store the names you see in the builder. It stores internal ids. An "Add tag: Hot Lead" action does not save the text "Hot Lead" — it saves something like tag_7c1f…, the id of that tag in that one account. A custom-field condition saves the field's id, not its label. A "move to stage" action saves a pipeline id and a stage id.

Those ids are account-scoped. Create the very same "Hot Lead" tag by hand in a second account and it 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. The destination has no record with that id, and the reference dangles. A raw copy — or an exported JSON file — moves the structure but never reconciles these ids, which is why the references arrive blank.

What breaks: tags, fields, stages, users, calendars

The breakage is not random. It is every field in the workflow that holds an account-scoped id instead of a literal value:

• Tags. Add-tag and remove-tag actions, plus 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, and the matching is sensitive to the field's type.
• Pipeline and stage. "Create / update opportunity" and "move to stage" actions reference a pipeline id and a stage id within it; the stage id is meaningless without its parent pipeline.
• Users / assignees. "Assign to user" and round-robin steps reference user ids, and the same person has a different id in each account — or may not be a member of the destination at all.
• Calendars. Appointment and booking actions reference a calendar id.
• Templates and custom values. "Send email" or "send SMS" steps that use a saved template point at that template's id, and account-level custom values resolve by id too.

How name-based remap rewires each reference

ExportGHL Workflows treats a move as a reconciliation rather than a copy. You save the workflow from the source into a private cloud library, then deploy it into the destination as a new workflow. On a cross-account deploy, cross-account remap runs automatically: 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 tag, field, pipeline, stage, user, calendar or template.

Matching by name works because names are what the two accounts genuinely share. You rarely have the same internal ids across accounts, but you very often have a "Hot Lead" tag, a "Lead Source" field, and a "Sales Pipeline" with a "Booked" stage in both. Remap walks the full reference graph, so a remapped stage lands inside its correct remapped pipeline rather than any stage that happens to share a name. The deploy creates a brand-new workflow and never overwrites what is already in the account unless you deliberately choose to update one.

What happens to references with no match in the destination

Sometimes a name genuinely is not present in the destination — the "Hot Lead" tag was never created there, or a user is not a member. Remap 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 imports the workflow as a draft. You create the missing record, or map the step to an existing one, and publish only when everything resolves.

That draft-by-default behaviour is the whole safety story. The failure you are avoiding is a workflow that looks live but quietly misbehaves — the same root cause behind a workflow not triggering after a copy. The end-to-end move, with remap in place, is walked through in copy a workflow between accounts.

Preparing the destination so more matches succeed

The match rate is in your hands. Before you deploy, set the destination up so there is something for each reference to land on:

1. Create the tags and custom fields the workflow uses, with the same names as the source. For fields, match the field type as well — a text field and a dropdown with the same label are not interchangeable.
2. Build the pipelines and their stages the workflow references, keeping stage names consistent so each one maps into the right pipeline.
3. Add the users that assignment and round-robin steps rely on, and set up any calendars the booking steps point at.
4. Keep spelling and casing consistent. Matching is by name, so "Hot Lead" and "hot lead" are two different things to the matcher.

You do not have to build all of this by hand. The opt-in auto-create toggle builds the missing pipelines — with their stages — and tags in the destination for you as it deploys, so the manual prep comes down to the things it cannot fabricate: email and SMS templates, calendars, and users.

One honest caveat: remap rewires the references inside the workflow, but it does not move your sending infrastructure. The domain, from-address, phone number and A2P registration that email and SMS steps rely on are configured per account and do not travel with a workflow, so reconnect those in the destination after deploying. Prepare the account first and far fewer references drop to draft.

Frequently asked questions