Updating a snapshot that is already live: versions, pushes and what gets overwritten

You improved the source account. You fixed a wait step, rewrote three messages, added a branch that should have been there from the start.

Nothing changed for any client. Not one of them.

A deployed sub-account is a copy, and copies do not follow their original. This is the fact almost nobody learns until the day it costs them something, and the second half of it is worse: the mechanism that does push your improvements out is not free, and it can take a client’s own work with it.

Deployed accounts are independent

When a snapshot loads into a sub-account, the assets become that account’s assets. They are not linked in the sense of staying in sync. They are a print taken from a plate, and the plate can be recut without anything happening to the prints already hanging on the wall.

That independence is mostly a feature. It means a client editing a workflow cannot break your source, and a mistake in your source does not detonate across forty accounts overnight. It also means every improvement you make is an improvement nobody has until you deliberately hand it to them.

Refresh, version and push are three different actions

They get used interchangeably in conversation and they do entirely different things.

Refresh pulls the current state of the source sub-account back into the snapshot. Nothing outside the snapshot changes. You are updating the plate, not the prints. Do it before anything else, because a push that goes out before a refresh sends the old build with fresh confidence.

Version is what a given sub-account actually received. Two accounts that took the same snapshot four months apart are running different software, and neither of them knows it. Creating a new version does not reach back and touch accounts that took an earlier one.

Push sends a newer version to accounts that previously loaded that snapshot. This is the only one of the three that changes anything at a client.

All three live in Agency View, under Account Snapshots.

What a push does to work somebody did by hand

Here is the part worth reading twice.

A push adds what is new, and it replaces what came from the snapshot with the newer version of that same asset. That second half is where the damage lives. If a client, or your own team, edited a workflow that arrived in the snapshot, that edit is sitting on a snapshot-linked asset, and the push overwrites it.

Assets built fresh inside the sub-account, a workflow somebody created from scratch, a funnel that never came from the crate, are not part of the snapshot and are not touched.

So the risk is not random. It is precisely proportional to how much hand-editing has been done to the things the crate delivered, which on a well-fitted account is quite a lot. Most crates get their message copy rewritten during fit-out, because sending stock copy is the fastest way to sound like a template. That rewritten copy lives on a snapshot-linked asset.

The discipline that makes pushing safe

Four habits, and they cost nothing if you start with them and a great deal to retrofit.

Never edit a snapshot-linked asset in place. Duplicate it, edit the copy, publish the copy and pause the original. The duplicate is now the account’s own asset and no push can reach it. This is the single rule that turns pushing from a gamble into an operation.

Keep a register of which version each account holds. A column in whatever you already use to track clients. Without it, “push to everyone” is the only move available, and “push to everyone” is how one bad build becomes forty support conversations.

Push to one account first and leave it a day. Pick an account you own or a cooperative client, push, then watch a real contact move through the changed part. A day of real traffic finds things no amount of staring at the builder will.

Push outside business hours. A workflow being replaced while contacts are actively sitting inside it is not a good moment. Late evening, and then check the first live contacts the next morning the way you would after a fresh import.

If something does go quiet after a push, work down the diagnostic order for a snapshot that will not fire rather than immediately pushing again. A second push on top of a broken state usually just doubles the confusion.

Accounts you cannot push to at all

Push only reaches sub-accounts inside your own agency.

If you shared a snapshot by link and another agency imported it into their own account, there is no channel back. They are not on your version list and never will be. The only way they receive an improvement is by taking a new link and loading it themselves, which means you are now in the business of release notes.

Send three things with every new link: what changed, what it replaces, and what they will lose if they load it over a fitted account. That last one is the sentence they need and never get. Agencies handing snapshots to other agencies should read the same warning they would want, and the reusable onboarding snapshot post covers packaging that handover properly.

The same applies in reverse when you buy. A crate from the depot is loaded into your account and it becomes yours. We do not push into accounts we do not hold, which is deliberate: nobody should be able to change your live automations without you deciding to let them.

When not to push

Most improvements are not worth the trip.

A tidier internal workflow name, a folder reorganisation, a comment. None of that reaches a customer and none of it justifies replacing live assets across a roster. Batch cosmetic work and let it ride until something real needs to go out with it.

Push when the change is one of three kinds: something is genuinely broken in the shipped build, something has become non-compliant, or something materially changes what the customer receives. A missing stop condition on reply is worth a push at midnight. A renamed pipeline stage is not.

The arithmetic is simple enough to do in your head. If you run twelve accounts and a push costs you fifteen minutes of checking each, that is three hours to hand out a change nobody asked for. Illustrative numbers, but the shape holds at any roster size, and it gets worse as the roster grows.

Rolling one crate across many accounts

If you are pushing regularly it is usually because one crate is doing duty across a group of similar businesses. That is the right use of a snapshot and it has its own operating requirements.

The parts that differ per account should live in custom values rather than inside the assets themselves, so that a push replaces the machinery and leaves the identity alone. That is exactly what custom values across sub-accounts are for, and getting that boundary right is what makes the difference between a push you can do on a Thursday and a push you schedule a week for.

Where the roster spans several trades rather than several branches of one, the multi-niche agency rollout service covers the naming standard and batch fitting, and the white label support desk covers being the person clients call after a version goes out. A roster of trade accounts running the HVAC contractor crate and the plumbing company crate side by side is two version registers, not one, and the home and trade aisle lists the rest of that shelf.

What to decide next

Decide, before your next push, whether your accounts have been edited in place or edited by duplication. If it is the former, the first job is not the push. It is going through the accounts that matter and copying the hand-written parts out of harm’s way.

Then decide how many crates you are actually maintaining. Every additional one is another source account, another version register and another push cycle, which is a real argument for standardising on fewer. The full catalog is the place to work that out.