Workflows are where the real engineering lives in a GoHighLevel sub-account. Contacts can be re-imported from a spreadsheet. A funnel can be rebuilt from screenshots in an afternoon. But a mature workflow, with its branching conditions, wait steps, tag logic, and webhook calls tuned over months of client work, exists nowhere except inside the builder. Lose it and you are rebuilding from memory.
So here is the direct answer to the question in the title: HighLevel has no way to export a workflow to a file. There is no download button, no JSON export, no scheduled backup. What it has instead is a set of partial protections, each covering a different way workflows die. Version history covers bad edits. The Deleted tab covers accidental deletion, for a while. Snapshots and cross-account copies cover duplication, with caveats. None of them puts a copy of your automation logic anywhere outside HighLevel.
That gap is worth understanding in detail, because each native option fails in a different place.
Can you export a HighLevel workflow?
No, and it is not for lack of asking. Exporting and importing workflows as JSON files has been a popular request on HighLevel’s public ideas board for years. As of this writing, it has not shipped.
The API does not close the gap either. HighLevel’s public API can list the workflows in a location, with basic details like name, ID, and status. What it cannot do is read the contents of a workflow: the triggers, the actions, the branching logic that makes it valuable. There are no endpoints to create or modify workflows, which is itself a long-standing feature request. So even a technical team comfortable building their own backup pipeline can only capture an inventory of workflow names, not the workflows themselves.
This makes workflows unusual among HighLevel objects. Contacts at least have a CSV export, however incomplete. Workflows have nothing that leaves the building.
What protection does HighLevel give you out of the box?
Two features, both added in recent years, and both useful for what they cover.
Version history keeps a timeline of a workflow’s saved states, up to 10 versions or 30 days, whichever runs out first. Open a workflow, click the version history icon, and you can restore any previous version as a new draft, or branch it into a separate workflow. Your published workflow stays untouched until you publish the restored draft. If a teammate mangles the branching logic on a Tuesday, this is how you get Monday back.
The Deleted tab covers the blunter failure. Deleted workflows appear on a Deleted tab on the workflow list page, where Location and Agency Admins can restore them for 90 days. Restored workflows come back in draft mode with their original triggers and actions intact, though their folder permissions reset. After 90 days, the workflow is removed from the tab and there is no next step.
| Native option | Protects against | Window | Where the copy lives |
|---|---|---|---|
| Version history | Bad edits | 10 versions or 30 days | Inside the same workflow |
| Deleted tab | Accidental deletion | 90 days | Inside the same sub-account |
| Snapshot | Rebuilding from scratch | Point in time, goes stale | Inside the agency account |
| Copy to sub-account | Single-account loss | Point in time, goes stale | Another sub-account, same agency |
Read the last column carefully. Every one of these copies lives inside HighLevel, under the same agency account. That is the pattern to keep in mind for the rest of this post.
Do snapshots or copies count as a workflow backup?
More than they do for contacts, less than people assume.
Snapshots are HighLevel’s tool for copying a sub-account’s configuration, and workflows are part of what they capture. This is why snapshots have a better reputation as workflow protection than as data protection: they carry no contacts, conversations, or opportunities, but they do carry automation structure. If you take a snapshot today, you can load today’s workflows into a fresh sub-account later.
The limits are the same ones snapshots always have. A snapshot is frozen at the moment you take it, so unless someone re-snapshots after every meaningful edit, the copy drifts away from reality. And loading a snapshot into another account strips the references that made the workflow work, because IDs for calendars, users, and pipelines do not travel.
The copy-to-sub-account feature is the lighter-weight version of the same idea. An Agency Admin can copy a single workflow directly to another sub-account, where it arrives in draft state. HighLevel’s documentation is specific about what travels with it: contact tags, contact custom fields of matching type, custom values, opportunity custom fields, pipelines and stages, and text templates for email and SMS. Everything else, and this is the documented behavior, is cleared or removed from the workflow before copying. Webhook URLs, calendar assignments, user references: the copy needs rewiring before it can run.
Both features are duplication tools that can be pressed into service as backups. Neither was built for it, and both copies still sit inside the same agency account as the original.
What can still go wrong?
Walk through the failure cases and watch which ones slip past every native option.
An edit that went wrong more than 30 days ago is beyond version history’s reach, and version history only holds 10 versions, which a busy team can burn through in a week of tweaking. A workflow deleted 91 days ago is out of the Deleted tab. A snapshot from March does not contain the logic you built in June.
Then there are the failures that take the container with them. If a sub-account is deleted, the 24-hour undo window belongs to the agency, and after it closes, the workflows inside are gone along with the version history and the Deleted tab that might have saved them. If the agency’s own subscription lapses, every sub-account under it starts losing access on a schedule, and the snapshots stored at agency level disappear with the agency account. HighLevel does keep roughly 7 days of infrastructure-level database backups, but those exist for the platform’s own disaster recovery. There is no process for requesting a restore of your workflow from them.
The uncomfortable summary: HighLevel’s workflow protections all assume the surrounding account keeps existing. The scenarios that destroy accounts are exactly the ones they cannot cover.
How do you actually back up HighLevel workflows?
With no export and no meaningful API access, your options come down to discipline or tooling.
The discipline version looks like this: take a fresh snapshot of each sub-account on a schedule, monthly at minimum, weekly for accounts under active development. Document your most valuable workflows outside HighLevel, with full-page screenshots of the builder canvas and a written note of every webhook URL and external reference, because those will not survive a snapshot load. Test-load a snapshot into a spare sub-account occasionally so the first time you rely on one is not during an emergency. This works, in the sense that a fire drill works. It also depends on someone doing it every week forever, and it still keeps every copy inside HighLevel.
The tooling version is why we built GHLArmor, and since it is our product, take the recommendation with that in mind. GHLArmor is the first backup approved by the HighLevel Marketplace, and it captures workflows continuously alongside contacts, conversations, custom fields, and opportunities, storing the copies outside HighLevel entirely. That last part is the point of this whole post: a backup that lives in the same account as the thing it protects is a copy, not insurance. When a workflow is deleted past its 90-day window, or a sub-account vanishes, or an agency account lapses, the restore has to come from somewhere the failure cannot reach. We compared the available approaches, ours included, in our roundup of HighLevel backup tools.
Whichever route you take, the native features are still worth using. Version history and the Deleted tab are good safety nets for everyday mistakes, and they cost nothing. Just be clear about what they are: guardrails inside the building, not a copy of the blueprints stored off-site.
Frequently asked questions
Can I export a HighLevel workflow as a file? No. HighLevel has no feature that exports a workflow to a file you can store outside the platform. Exporting workflows as JSON has been an open feature request on the HighLevel ideas board for years. Every native option keeps the workflow inside HighLevel’s ecosystem.
How long do I have to restore a deleted HighLevel workflow? Deleted workflows sit in a Deleted tab on the workflow list page for 90 days, and Location or Agency Admins can restore them from there. Restored workflows come back in draft mode, so you need to review and republish them. After 90 days they are removed from the tab and gone.
Does workflow version history count as a backup? Only partially. Version history keeps up to 10 versions or 30 days of a workflow’s saved states, and you can restore any of them as a new draft. It protects against bad edits, but it lives inside the same sub-account as the workflow, so it disappears along with everything else if the sub-account is deleted or the agency account lapses.
Do HighLevel snapshots back up workflows? Snapshots do capture workflow configuration, which makes them more useful for workflows than for contacts. But a snapshot is a point-in-time copy that goes stale the moment you keep editing, it strips account-specific references when loaded elsewhere, and it lives inside the same agency account it is supposed to protect.
Can I back up workflows through the HighLevel API? Not meaningfully. The public API can list workflows with basic details like name and status, but it exposes no endpoints to read a workflow’s triggers and actions, and none to create or update workflows. Full workflow API access is an open feature request.