You copied a workflow into a new account, switched it on, and the steps are firing — but the emails and texts never arrive. Almost always this is per-account sending setup that stayed behind, not a broken workflow. Here is exactly what to reconnect.
A copied workflow that runs but never sends is one of the most common surprises after a cross-account move, and it rarely has anything to do with the workflow itself. Contacts enter, waits count down, tags get applied, branches resolve — the build came across intact. What did not come across is the sending infrastructure underneath it, because in GoHighLevel that infrastructure lives in the account, not in the workflow. This guide walks through each piece you have to reconnect in the destination, and is honest about which parts a copy tool can wire up for you and which it cannot.
It helps to separate two different failures. If your emails do send but the merge fields come out blank, that is a data problem — the contact record or custom field a template pulls from is empty or was never mapped, and it is a different fix. This guide is about the other case: the send step itself does nothing. No email leaves, no SMS is dispatched, and often there is no loud error in the workflow — the step just quietly produces nothing and the contact moves on to the next action.
That happens because a "send email" or "send SMS" action is only the instruction to send. The thing that actually does the sending — a verified domain, a from-identity, a provisioned phone number, a messaging registration, a saved template — is configured at account level and merely referenced by the step. Move the workflow and the instruction comes with it; the account-level plumbing it points at stays behind in the source account.
Email delivery in GoHighLevel depends on a sending domain you verify (the DNS records that let your mail be sent as your domain) and a from-address built on top of it. Both are set up inside a single sub-account and are scoped to that account. A workflow does not carry your domain verification or your sending identity; it only holds a reference to the from-address you picked when you built the step.
So in the destination account you have to verify a sending domain of your own and create a from-address before any email step can deliver. Until you do, the from-address field on each send-email action has nothing to resolve to and typically shows blank. Once the domain is verified and a from-address exists, you open each email step and select it. This is a one-time setup per account — once the domain is live, every workflow you deploy into that account can use it.
SMS has the same shape, with an extra layer. Texting requires a phone number provisioned in the destination account, and — in the US and Canada — A2P 10DLC registration tying a brand and a campaign to that number. None of this is stored in a workflow. A2P registration in particular belongs to the sub-account's own brand and number, so there is no mechanism by which copying a workflow could bring it across.
The practical consequence: an SMS step will not deliver from a new account until that account has its own connected number and completed A2P registration. If you moved an automation that was texting happily in the source account and the texts have gone silent, the number and registration are the first things to check. This is genuinely separate from the workflow, and it is work you do once in each destination account rather than per workflow.
Templates are the one piece of this that is inside the workflow — and even then only as a reference. A "send email" step that uses a saved template stores the template's id, not its contents, and those ids are account-scoped, exactly like pipelines, tags and custom fields. Drop the id into another account and it points at a template that does not exist there, so the step has no body to send.
This is the part that behaves like the rest of a cross-account move, which means it is also the part a copy tool can reconcile for you. The underlying mechanism is the same name-based matching described in the cross-account remap guide: if a template with the same name already exists in the destination, the reference can be rewired to it. Inline message text typed directly into a step, by contrast, is a literal value and simply copies across as-is.
Before you switch a freshly deployed workflow on, walk this list in the destination account:
The end-to-end move that gets the workflow into the account in the first place is covered in copy a workflow between accounts; this checklist is the sending layer you add on top once it has landed.
When you deploy a saved workflow with ExportGHL Workflows across accounts, cross-account remap runs automatically, matching the account-scoped references inside the workflow — including email and SMS templates — by name against the destination and rewriting the ids. A template that already exists there is wired up for you, so that particular cause of a non-sending step is handled automatically. Anything it cannot match is flagged, and the workflow is deployed as a draft rather than published, so you never end up with a live automation quietly failing to send.
Be clear about the boundary, though: remap reconciles what lives inside the workflow. Your sending domain, from-address, phone number and A2P registration are account-level infrastructure that no workflow carries, so no copy tool — ours included — can bring them across. Those are the checklist items above, reconnected once per account. If a step still will not send after a workflow comes across cleanly, the cause is almost always one of those per-account connections. A related check when nothing fires at all is in workflow not triggering after a copy.
Deploy one workflow into another account free. Templates remap by name and anything unmatched is flagged to draft — so you know exactly what sending setup is left to reconnect.
Start free
ExportGHL