How to Clone a GoHighLevel Review Request Workflow

A review-request workflow is one of the most reusable automations an agency builds. The logic barely changes from client to client: a job finishes, you wait a little, then you ask the happy customer for a review. Rebuilding it by hand in every new account is wasted effort — and GoHighLevel gives you no clean native way to move it across. This guide covers what the workflow contains, why it is such a good candidate to templatize, and how to clone it with ExportGHL's save-and-deploy model.

What a review-request workflow does

A review-request workflow automates the ask that most businesses forget to make. It fires after a good experience — a completed appointment, a closed job, an invoice marked paid — waits a short while, then sends a message asking for a review, usually with a direct link to the business's Google profile.

Better versions branch on the response — happy customers go to the public review link, unhappy replies to a private feedback form so complaints stay off the public page. The point is consistency: every customer gets asked at the right moment, automatically.

Its trigger, timing and message steps

Strip a review-request workflow down and it is nearly always the same handful of pieces:

• A trigger — most commonly an appointment status changed to "Showed" or "Completed", a tag added such as "job-done", or an opportunity moved into a "Won" or "Completed" pipeline stage.
• A wait — a delay of a few hours to a couple of days, so the ask lands after the experience but before they have forgotten it.
• One or more messages — an SMS and/or email carrying the review link, often with a follow-up a day or two later if the first goes unanswered.
• Optional branching — the satisfaction question that sends happy customers to the public review and routes everyone else to private feedback.
• Settings — business-hours windows and whether a contact can re-enter the workflow.

The message content carries the client's brand and Google profile; the structure around it is near-identical across accounts.

Why it is the same across most clients

That structure is what makes review-request workflows so reusable. A dentist, a plumber and a gym all want the same shape: finish, wait, ask, branch. What differs between clients is small and specific — the tag or stage that marks a job done, the wording, the wait length, and the Google review link. This is why experienced agencies templatize review requests first: the build travels, only the details change.

The problem has always been moving that build. GoHighLevel's native duplicate copies a workflow only inside the one sub-account you are in, and a snapshot drags a whole-account template across when all you wanted was one automation in an already-live account.

Cloning it with save and deploy

ExportGHL treats a clone as three steps — save, a free readiness check, then deploy — so the same saved workflow can be reused as many times as you have clients. The side-panel extension reads it straight out of the builder through its server proxy.

1. Open the source workflow in the sub-account that holds the review request you have perfected.
2. Save it to your library. The whole build is captured — the trigger, every action in order, the waits, the branches and the settings — and kept as a reusable item you can version over time.
3. Open the destination account you want the review request to run in.
4. Run the free readiness check. Before deploying, run the check: it previews what will map, what the opt-in auto-create toggle can build for you, and what you must set up yourself — no credit spent and nothing deployed.
5. Deploy as a new workflow. On a cross-account deploy, remap runs automatically. It arrives switched off, so nothing fires until you have checked it and turned it on.

Because the workflow lives in your library, cloning it into the next client is just another deploy. There is no mass "copy to every account" button and no scheduler; it is a repeatable deploy, one account at a time. Deploying always creates a new workflow and never overwrites an existing one unless you deliberately choose to update it, so you can drop it into a live account without replacing anything. The end-to-end move is in copy a workflow between accounts.

How remap handles the trigger and references

A workflow is full of ids that only exist in its original account — the tag that fires the trigger, a pipeline stage, a user, a custom field, a calendar. Dropped into another account untouched, they point at nothing. On a cross-account deploy, cross-account remap runs automatically and ExportGHL matches each reference by name against the destination and rewrites the id to the one that lives there, so the trigger fires off the right tag or stage and the actions wire to the right pieces. The full mechanism is in cross-account workflow remap.

One honest limit matters for review requests. Remap rewrites references — tags, stages, users, custom fields, templates — matched by name; it does not touch literal text inside a message. If the review link is typed into the SMS or email, it copies verbatim and still points at the source client's Google profile, so you must swap it per client. Keeping the link in a custom value makes that a one-field change each time.

Dropping it into a new client account

After the deploy lands as a draft, a short checklist gets it live in the new account:

• Swap the review link to the destination client's own Google profile — this is the one piece that does not remap automatically.
• Reconnect the sending infrastructure. The phone number, from-address and A2P registration are per-account and do not travel with the workflow — the steps copy, but the destination must be able to send SMS and email on its own.
• Check the trigger matched the right tag or pipeline stage in the destination, and resolve anything remap flagged.
• Read through the draft once, confirm the wait timing and the branch logic look right, then publish and switch it on.

Done once per client, this is far faster than rebuilding from scratch each time. You can move your first workflow on the free trial with no card, then switch to pay-as-you-go credits that never expire or a one-time Toolkit licence — the pricing page lays out both. For the wider pattern across a book of clients, see reuse workflows across sub-accounts.

Frequently asked questions