How to Export a GoHighLevel Workflow as JSON

Why there is no export button in GoHighLevel

If you have gone looking for a way to export one workflow out of GoHighLevel as a file, you already know the answer: there isn't one. The platform can duplicate a workflow within the same sub-account, and an agency admin can use Copy Workflow to Sub-Account to send one to another sub-account in the same agency — but that copy lands as a draft and clears most references, and there is no menu that produces a file, no native path to a different agency or a client's own account, and nothing that gives you an off-platform backup. Snapshots exist, but they copy a whole-account template, which is the wrong tool when you only want to move one or a handful of automations into accounts that already have contacts, pipelines and settings you do not want to disturb.

So when people search for a GoHighLevel workflow export "as JSON," what they are really after is a portable copy of the automation — something that holds the full logic of the workflow and can be rebuilt somewhere else without doing it step by step. That is a reasonable thing to want, and it is exactly what ExportGHL Workflows produces.

What a workflow export actually contains

A workflow is more than a list of actions. To reproduce it faithfully, an export has to capture three things:

• The action graph. Every step in order, plus the branches, wait timers, if/else conditions and goals that connect them. The structure is the workflow; losing a branch means losing behaviour.
• The triggers. What starts the workflow — a form submission, a tag added, a pipeline stage change, an inbound message, and the filters on each trigger.
• The per-step settings. For each action, the thing it points at: the email or SMS template, the pipeline and stage, the tag, the custom field, the assigned user, the calendar. These are the details that make an automation do its job.

Capture those three layers and you have the complete automation, not a sketch of it. That is the difference between something you can study and something you can actually run.

The problem hiding inside raw JSON

Here is the catch, and it is the reason "export as JSON" is more complicated than it sounds. Inside that captured workflow, the pipelines, stages, tags, users, custom fields and calendars are not stored by name — they are stored as ids that only mean something in the account the workflow came from. Pull the raw JSON out of one account and drop it into another, and those ids point at nothing. The steps survive, but they reference pipelines and fields that do not exist in the destination, so the automation is effectively broken until someone fixes every reference by hand.

How ExportGHL makes the export portable

Rather than handing you a loose JSON file to wrangle, ExportGHL Workflows saves the whole workflow to a cloud library. Think of it as a shelf of portable workflows you can reach from any connected account. When you deploy one into another sub-account or agency, two things happen that a raw export cannot do:

1. It deploys as a new workflow. The automation lands in the destination as a fresh workflow and never overwrites what is already there — unless you deliberately choose to update an existing one.
2. Cross-account remap rewrites the ids. Every reference that only existed in the source — pipelines, stages, tags, users, custom fields, email templates — is matched to its counterpart in the destination by name and rewritten to the correct local id. A step that pointed at the old account's "Sales" pipeline now points at the new account's "Sales" pipeline.

If something in the workflow has no match in the destination — a tag or custom field that simply does not exist there yet — ExportGHL does not guess and does not publish anything half-wired. The workflow is left as a draft so you can create the missing piece, map it, and publish when it is genuinely ready. That "never publish broken" default is deliberate: a live automation firing against the wrong stage is worse than one that waited a minute for you to finish.

How this compares to the JSON exporters

Other tools in this space — GHL Workflows Pro, GHL Workflow Importer/Exporter and GHL Workflows JSON Exporter among them — will export workflow JSON for you. (Super Cloner is sometimes mentioned alongside them, but it clones funnel and website pages, not workflows.) That is genuinely useful if all you need is a backup or a reference. What they do not do is remap cross-account ids. Move their output into a different account and you are back to fixing references by hand, which is most of the work. If you are weighing the options, the workflow cloner comparison lays out who remaps and who only dumps a file.

The short version: a JSON export answers "can I get the workflow out?" The remap answers "will it work when it lands?" For moving automations between real, live accounts, the second question is the one that matters.

A practical workflow for moving one automation

If your goal is to lift a single workflow out of one account and stand it up in another, the sequence is straightforward:

1. Open the source account in ExportGHL Workflows and save the workflow to your cloud library.
2. Check the destination account has the named pipelines, tags and custom fields the workflow relies on (or let the draft tell you what is missing), and flip on auto-create to have ExportGHL build any missing pipelines, their stages and tags for you, leaving templates, calendars and users to set up by hand.
3. Deploy from the library into the destination — on a cross-account deploy, cross-account remap runs automatically, matching references by name — and review anything left as a draft.
4. Fill in any unmatched references, then publish.

You can try the whole path before paying anything — the free trial lets you move up to 3 workflows with no card. For a fuller walkthrough of deploying into a second account, see clone a workflow, and check pricing for the pay-as-you-go credits and one-time Toolkit licence.

Frequently asked questions