You imported a workflow, opened the destination account, and it is sitting there as a draft that will not go live. Before you hunt for a bug, know that this is usually the import working exactly as designed — and the draft is telling you something useful.
A draft feels like a failure, but in a careful import it is not an error state — it is a deliberate pause. Something in the workflow pointed at a record the destination account does not have yet, so rather than publish a broken automation, the import held it back and flagged what it could not resolve. This guide explains why that happens, how to read what is flagged, and how to publish once the build is wired to the right pieces.
A GoHighLevel workflow is wired to the account it was built in by internal ids, not by names. An "add tag" action stores the id of a tag, not the text "Hot Lead"; a "move to stage" action stores a pipeline id and a stage id. Those ids only exist in the source account. When you deploy that workflow into a different account with ExportGHL Workflows, cross-account remap reads each account-scoped reference, looks up its name, and finds the record with the same name in the destination — rewriting the id so the action points at the right thing. The mechanics of that match are covered in cross-account workflow remap.
Most references match cleanly, because the two accounts usually share the obvious names — a "Sales Pipeline", a "Lead Source" field, a "Hot Lead" tag. But when even one reference has no match — a tag that was never created there, a user who is not a member — there is nothing to rewrite the id to. Rather than publish a workflow with a dangling reference, the import holds it as a draft and flags the item. That is why it will not go live: it is waiting for you.
Consider the alternative: a workflow published anyway looks live but mis-fires the instant a contact reaches the unmatched step. GoHighLevel will often let a workflow run with a dangling reference — the action does nothing, or the wrong thing — and you do not find out until a real lead has slipped through.
So a draft is not a failed import; it is the import pausing on something to decide. The structure — every trigger, action, wait and branch — came across intact; what is pending is a short list of references that could not be matched.
When a deploy lands as a draft, it comes with a list of exactly what could not be matched. Each flag tells you three things:
That last part saves the time: instead of "this workflow has a problem", you get "the Add tag step wanted a tag called Hot Lead, and there isn't one here." The flag is a precise instruction, not a vague warning, and the list is usually short — one or two items in a typical move, because everything else matched cleanly.
You have two clean ways to clear a flag, and which you choose depends on whether the destination should have that record at all:
One thing a workflow import does not carry is sending infrastructure. The domain, from-address, phone number and A2P registration are tied to the destination account, not to the workflow. Remapping rewires which tag or pipeline a step uses; it does not connect a sending domain or register a number for you. If the workflow sends email or SMS, set those up in the destination before you turn it on. The full end-to-end move is walked through in copy between accounts.
When the flagged list is empty, the workflow is wired to the destination's own records and behaves the way it did in the source. At that point publishing is a deliberate act, not an automatic one — you review the build, confirm the sends are connected, and switch it on yourself. That is the point of the draft stage: it hands you the decision instead of making it blindly.
Remember too that the deploy created a new workflow in the destination — it never overwrote anything already running there unless you explicitly chose to update an existing workflow. So you can take your time clearing flags with no risk that a live automation was replaced.
GoHighLevel's own cross-account moves leave you in a much worse position. A snapshot copies a whole-account template and the workflows inside it land inactive; the agency-admin-only "copy workflow" — where it is available, same-agency only — also arrives as a draft and expects matching custom-field types on the other side. In both cases the workflow is inactive, but nothing tells you why, or which references failed to resolve. You are left opening each step hunting for the blanks, and a dangling reference that does not visibly break is easy to miss.
The difference is not that ExportGHL leaves workflows in draft and GoHighLevel doesn't — both end up inactive. It is that ExportGHL turns the draft into a readable checklist: every unmatched reference named up front, by action and by record. If you are comparing tools on this behaviour, the cloner comparison lays out which ones remap and flag, and which just dump the JSON and leave you to it.
Deploy one workflow into another account free. Watch the references remap, read anything unmatched as a plain checklist, and publish only when it's wired right.
Start free
ExportGHL