THE SHORT VERSION
- Refresh and push are two separate actions. Pushing without refreshing sends the old version and looks like nothing happened.
- Updates only reach sub-accounts inside your own agency. External agencies have to re-import from a new link.
- A push adds and updates. It does not delete, and it does not reconcile a local edit against your central change.
- The rule that makes updates safe: clients never edit snapshot assets. Anything they need becomes a custom value or lives outside the prefix.
Every snapshot has a second life that nobody plans for. You build it, install it into nine accounts, and then three months later you need to change the reminder sequence — in all nine.
This is where a lot of agencies discover their snapshot was really nine snapshots.
The good news is that GoHighLevel supports this properly. The bad news is that it supports it with two separate actions people routinely conflate, and four limits that are easy to hit.
The two actions, in order
Refresh rebuilds the snapshot from its source sub-account. Your snapshot is a saved copy taken at a moment in time; editing the source account afterwards does not change it. Refreshing re-reads the source and lets you select which new or modified assets to include.
Push updates sends that snapshot to sub-accounts that previously loaded it. You select which accounts receive it.
They are separate, and the order is refresh then push. Pushing without refreshing sends the version you saved last time — the update runs, reports success, and changes nothing. That is far and away the most common “the update didn’t work” report, and it is not a bug.
So the loop is always:
- Make the change in the canonical source sub-account — the account the snapshot was taken from, which should not be a client’s.
- Test it there, properly, by running the journey.
- Refresh the snapshot, selecting the assets you actually changed.
- Push to a single account first.
- Verify in that account.
- Push to the rest.
Step 4 is not optional at any scale above about three accounts. A push you cannot undo, applied to twenty accounts at once, is how a broken workflow becomes twenty support tickets.
The four limits
1. Updates stay inside your agency
This is the big one and it reshapes how you buy snapshots. Pushing updates works for sub-accounts inside the agency that owns the snapshot. If a client’s sub-account lives in a different agency — which is the case for anyone who imported from your share link — your push cannot reach it. They re-import from a new link, and nothing reconciles what is already there.
The purchasing implication: when a vendor advertises “lifetime updates” on a snapshot you import into your own agency, what they mean is that they will give you new links, and merging each one is your work. That is a perfectly reasonable offer. It is just a different offer from the one most people hear, and it is worth confirming before you standardise twenty accounts on somebody else’s product. It is on the checklist in how to judge a GoHighLevel snapshot.
2. A push adds and updates — it does not delete
If version 2 of your snapshot removed a workflow, pushing version 2 does not remove it from the accounts that already have version 1. It is still there, still enabled, still firing.
This is the same non-destructive behaviour that makes importing safe, and it has the same consequence: deprecation is manual. Keep a changelog of what you removed and clean those up per account, or your client accounts accumulate dead automations that nobody remembers enabling.
3. There is no merge
Where you changed an asset centrally and the client changed the same asset locally, there is no reconciliation. One of the two versions wins and the other is gone.
Hence the operational rule that makes everything else work: clients do not edit snapshot assets. If a client needs a different message, it becomes a custom value. If they need an extra workflow, it lives outside the snapshot’s naming prefix so it is visibly not yours to overwrite. That prefix — every snapshot asset carrying a short identifier — is what makes this rule enforceable at a glance rather than from memory.
4. What cannot travel still cannot travel
An update carries configuration, not connections. Phone numbers, sending domains, payment accounts, Google Business Profiles and user assignments are per-account and stay that way. If your update adds a workflow step that sends from a specific number, that step arrives in twenty accounts pointing at nothing.
The fix is the same one that applies at install time: anything account-specific goes in a custom value, and anything that genuinely cannot go in a custom value goes on your written reconnection list. Both lists are covered in rolling one snapshot across every sub-account.
What to check before every push
A short pre-flight that catches most of it:
- Did I refresh? Confirm the snapshot’s last-updated timestamp changed.
- Did I select the right assets in the refresh? A partial refresh that missed the asset you changed is indistinguishable from not refreshing at all.
- Is the change safe to apply to an account mid-flight? Editing a workflow that contacts are currently sitting inside is different from editing one that is idle. Prefer building a new version alongside and switching the trigger.
- Does the change assume something not every account has? A new step referencing a service, a calendar or a user that only exists in the source account will land broken everywhere else.
- Have I got one test account to push to first? Preferably an account you own, not a client’s.
- Have I written down what this version changed? Because limit 2 means removals are your problem later.
Version discipline that scales
Once you are past a handful of accounts, treat the snapshot like software.
Version the name. Whatever scheme you like, as long as the snapshot name tells you which version an account is on. Without it, “which accounts have the new reminder sequence?” is unanswerable.
Batch changes. Do not push six times in a fortnight. Collect changes, test them together, push once. Every push is a risk event and a support surface.
Keep a changelog per vertical. Three lines per version: what changed, what was removed, what needs manual cleanup. This is the document that lets somebody who is not you run the next update.
Never take a new snapshot from a client account. It is tempting when the client’s account has the newest fix in it, and it is how client-specific data and settings end up shipped to every other account. Port the fix back to the canonical source and take it from there.
When the snapshot is not the right shape for updates
Sometimes the update pain is a design problem, not a process problem. If every update requires per-account cleanup, the snapshot is carrying things that should have been variables, and no amount of push discipline fixes that.
That is the point to rebuild it properly — how to create a GoHighLevel snapshot covers building for redeployment from the start — or to hand it over. A custom snapshot build is specified around exactly this: the update path is part of the design rather than something discovered afterwards.
Everything in our own library is built to be updated — prefixed naming, documented custom values, a written changelog per version — and every licence covers unlimited sub-accounts, so pushing to more accounts never costs more. Installation is free on any purchase, and the dedicated support attached to it is 12 hours to be used within 10 days — enough to cover the first update cycle as well as the install, provided you book it inside the window. After the hours or the window are gone, further help is quoted.