On this page

How to Hand Off GoHighLevel Workflows to a Client (Without the Whole Account)

A client is leaving or taking their account in-house, and you want to give them the automations you built — not a login to your account and not a snapshot of everything. Here is the clean handoff.

When a client leaves, takes their marketing in-house, or spins their sub-account out into their own agency, you are usually happy for them to keep the automations you built — the nurture sequences, the booking reminders, the pipeline logic. What you do not want is to hand over your entire GoHighLevel account, or ship them a snapshot of everything to move a handful of workflows. GoHighLevel gives you no clean way to pass over just the workflows, so this guide does it properly: save the ones that belong to the client, deploy them into their account as new workflows, and remap the references to the client's own objects.

When you need to hand off just the workflows

The handoff tends to come up at a few predictable moments: a client offboards and wants to take their marketing in-house; you are selling or transferring a sub-account; or an arrangement ends and you would rather part on good terms than hold their automations hostage. In each case the value is the build — the workflows you designed — not the shell of your account.

So the goal is narrow: the client ends up with working copies of a chosen set of workflows inside an account they control, while your own account and your other clients' work stay exactly as they were. That is a different job from a full account migration, and it needs a different tool.

Why a whole-account snapshot is too much

It is worth being clear about what GoHighLevel can and cannot do here, because the native tools almost fit and then stop short:

  • Duplicate only clones a workflow inside the same sub-account. It cannot send anything to another account, so it is no help for a handoff.
  • Snapshots move a whole-account template. They are built to stamp out new accounts, not to drop a few workflows into an account that is already live — applying one to a running account risks dragging in assets, settings and naming you never meant to share, and imported workflows land as drafts anyway.
  • GoHighLevel's own cross-account copy workflow, where it is available, is agency-admin only, works within the same agency only, lands as a draft, and needs the custom-field types to line up. The moment the client is on their own separate agency, it cannot reach them.

For a handoff, a snapshot is too much — you would be exporting your entire operational template just to give someone three workflows. What you want is surgical: the specific automations and nothing else.

This is the gap ExportGHL Workflows fills. Instead of a whole-account template, it moves individual workflows on demand into an account that already exists — and when that account belongs to a different agency, it still works, because the move runs through your cloud library rather than a same-agency link.

Selecting the workflows to hand over

ExportGHL works on a simple model: you save a workflow once, then deploy it where you need it. For a handoff, open each workflow that belongs to the client in your source account and save it to your private cloud library. The full build is captured — every trigger, every action in order, the waits, the branches and the settings — so the saved copy faithfully records how the automation runs.

Save only the ones that are genuinely theirs. This is where the handoff stays clean: you choose a deliberate set, not the whole account. Internal workflows, cross-client utilities and anything you reuse elsewhere stay unsaved and never leave.

Deploying them into the client's account

With the workflows saved, open the destination — the client's sub-account, or their own agency if they have added you — and go to its Workflows area. Deploy each saved workflow from your library and ExportGHL rebuilds it there as a new workflow.

Deploy never overwrites or edits anything already in the destination unless you deliberately choose to update an existing workflow, so there is no danger of disturbing automations the client already has. If you saved several, you deploy them one after another — save once, deploy as many times as the handoff needs, into as many accounts as it involves.

Remapping to the client's own objects

A workflow is full of references that only mean something in the account it was built in: pipelines and stages, tags, users, custom fields, calendars and templates are all stored as account-scoped ids, not names. Drop a raw workflow into the client's account and those ids point at nothing, so steps fail quietly — tags never land, opportunities never move, and the workflow looks fine in the editor while broken at runtime.

Cross-account remap is what makes the handoff actually work, and it runs automatically on a cross-account deploy. It matches every reference by name against the client's account and rewrites the ids to theirs, so the "Booked" pipeline stage, the "warm-lead" tag and the custom fields all resolve to the client's own records. Anything it cannot match is flagged, and if a workflow still has unmapped references it is imported as a draft — never published broken. You can read more about how that matching works in the cross-account id remap guide, and the mechanics are the same whether you are doing a handoff or an ordinary copy between accounts.

One thing remap cannot carry: sending infrastructure is per-account. The client's email domain and from-address, their phone number and their A2P registration do not travel with a workflow — those live on the account, not in the build. After deploying, the client (or you, working in their account) will need to confirm the destination's own sending setup is connected so emails and SMS actually go out.

A clean handoff checklist

  1. Confirm you can open the destination account — a sub-account you still manage, or the client's agency where they have added you.
  2. In the destination, make sure the pipelines, stages, tags, custom fields and calendars the workflows rely on exist and are named the same as in your source. Matching names give remap the cleanest result and the fewest flagged items. If a pipeline (with its stages) or tag is missing, the opt-in auto-create toggle can build it for you on deploy, leaving only templates, calendars and users to set up by hand.
  3. Save each client workflow from your source account to your cloud library — only the ones that are theirs.
  4. Deploy each saved workflow into the destination; cross-account remap runs automatically.
  5. Open anything that landed as a draft, resolve the flagged references, and publish when it is genuinely ready.
  6. Check the destination's sending setup — domain, from-address, phone, A2P — so the automations can actually send.
  7. Hand over. The client owns working copies in their own account, and yours is untouched.

If you are handing over the front end as well, the same clean-handoff thinking applies to the website — see handing off a GoHighLevel website to a client. Moving your first workflow is free, with no card, so you can run a full handoff end to end before deciding how to pay. See pricing for the credit and licence options.

Frequently asked questions

How do I give a client just my workflows, not the account?
Save each workflow you built to your ExportGHL cloud library, then deploy it into the client's own sub-account as a new workflow. They receive working automations rather than a login to your account or a snapshot of everything you run. The original stays in your account, and deploy never overwrites anything already in theirs.
Can I deploy workflows into a client's own agency?
Yes. Because the workflow passes through your cloud library rather than a direct account link, you can deploy it into any sub-account or agency you can open, including one that belongs to the client rather than to you. GoHighLevel's own cross-account copy, where it exists, is agency-admin and same-agency only, so it cannot reach a separate client agency the way save-and-deploy can.
Will the automations work with the client's tags and pipelines?
With cross-account remap running automatically, references are matched by name against the client's account — pipelines, stages, tags, users, custom fields and templates — and the ids are rewritten to theirs. Anything with no match is flagged and the workflow is imported as a draft rather than published broken, so you can create the missing object or pick the right one before it goes live.
Do I need access to their account to hand them off?
You need to be able to open the destination account to deploy into it, whether that is a sub-account you still manage or the client's own agency where they have added you. If you have already lost access, the cleaner path is to deploy into an account you can still reach and hand that over, or have the client add you briefly so you can deploy, then remove you once it is done.

Hand off workflows your client owns

Save the automations that belong to them, deploy them into their account remapped, and leave the rest of your account untouched. Your first move is free.

Start free