Snapshots for Agency Rollout: What Transfers and What Silently Doesn't

A GoHighLevel snapshot transfers selected configuration assets, not a working copy of the source sub-account. Customer records, account history, connections, approvals and destination-specific assignments stay behind, while several copied assets arrive as drafts or require configuration before they operate. Treat every rollout as a controlled deployment with a transfer matrix, a manual version cycle and asset-level verification.

The snapshot transfer table

The dangerous snapshot failure is not always an error message. An asset can appear in the destination while remaining unpublished, disconnected or incomplete. Other items never appear in the asset picker, so a person checking only whether the load completed will miss them.

The current snapshot include and exclusion lists divide rollout items into four practical states:

State	Assets or data	What the destination receives	Required action
Included configuration	Agent Studio, Brand Voice, Conversation AI, Voice AI Agents, workflows and triggers	Selected automation and AI configuration assets	Test connections, assignments and execution paths before activation.
Included configuration	Calendar groups, service add-ons, service categories, service resources, services and calendars	Selected scheduling structure	Verify destination-specific configuration before accepting bookings.
Included configuration	Custom fields, custom objects, custom values, pipelines, tags and trigger links	Selected CRM structure	Confirm names and references before loading workflows that use them.
Included configuration	Blogs, campaigns, email templates, forms, funnels, websites, quizzes, section templates, Social Planner, surveys, and text and email templates	Selected marketing assets	Publish and connect destination-specific dependencies where required.
Included configuration	Custom metrics, custom reports and non-private dashboards	Selected reporting assets	Make required source dashboards non-private and select the default dashboard explicitly.
Included configuration	Certificates, membership offers, membership products and webinars	Selected membership and learning assets	Inspect the destination copy before client use.
Included configuration	Brand custom color, Design Kit, documents and contracts, folders, knowledge bases, review settings and WhatsApp templates	Selected brand, document, reputation-setting and communication assets	Complete integrations and approvals attached to the destination.
Included configuration	Google, LinkedIn and Meta ad campaigns	Selected campaign assets	Inspect status, connections and platform-specific dependencies.
Included configuration	WordPress site	The selected site asset	Reconnect domains and re-authenticate licenses that require it.
Transferred but not live	Funnels and websites	Draft copies	Connect a custom domain and publish them.
Transferred but not operational	WhatsApp templates	Template assets without automatic usability	Connect WhatsApp and obtain Meta approval after import.
Transferred but not operational	Voice AI Agents	Agent configuration without an assigned destination phone number	Assign a phone number in the destination.
Transferred in reduced form	LinkedIn campaigns	Campaigns in Draft status, even without a destination LinkedIn connection	Connect LinkedIn and rebuild the excluded Lead Gen Forms.
Excluded	Contacts, appointments, conversations, conversation history and messages	Nothing	Do not use a snapshot as a customer-data migration.
Excluded	Reputation data, live account activity and contact-to-contact associations	Nothing	Plan separately for any required destination data.
Excluded	Stripe connections, integrations and third-party account connections	Nothing	Reconnect them inside each destination account.
Excluded	Assigned Voice AI phone numbers and LinkedIn Lead Gen Forms	Nothing	Assign or rebuild them after loading.
Excluded unless changed first	Private dashboards	They do not appear in the snapshot asset picker	Make the source dashboard non-private before creating or refreshing the snapshot.
Excluded	Assets protected by another creator’s Assets Protected Snapshot settings	Nothing	Remove the protected dependency from the rollout plan.

Enabled features, assets present in the source and the selections made during snapshot creation determine what appears in the snapshot. Inclusion therefore starts with the source account but ends with the exact picker selections made by the operator.

Transferred does not mean ready

Funnels and websites demonstrate the difference between transfer and operation. HighLevel loads them into the destination as drafts; it does not connect the destination’s custom domain or publish them. A visual inspection confirms that the pages exist but does not prove that visitors can reach them.

The same distinction applies to communication and AI assets. A copied WhatsApp template still requires a WhatsApp integration and Meta approval. A copied Voice AI Agent still requires a destination phone-number assignment. WordPress sites can require domain work and re-authentication for third-party plugin or theme licenses.

LinkedIn has an additional split. An existing-account load creates LinkedIn campaigns in Draft status even when the destination has no LinkedIn connection. The import completes, but LinkedIn Lead Gen Forms do not transfer. The campaign’s presence is therefore poor evidence that the acquisition path survived the rollout.

Build acceptance tests around operation, not inventory. Submit each copied form, exercise the connected workflow path, inspect the resulting pipeline action, open each public URL and confirm every channel-specific assignment. A list of asset names proves only that objects were created.

Load Snapshot and Push Update solve different problems

Load Snapshot initially adds selected assets to an existing sub-account or adds more snapshot content later. The documented route is Agency Dashboard → Sub-Accounts → three-dot menu → Manage Client → Actions → Load Snapshot.

During that load, HighLevel checks for conflicts. For every detected conflict, Override replaces the destination item with the snapshot version, while Skip preserves the destination item and excludes the conflicting snapshot asset. Override cannot be undone. Client data is not generally deleted by a load, but the conflicting configuration asset is replaced when Override is selected.

Loading multiple snapshots into one account increases the number of possible overlaps. A shared tag, form, workflow or pipeline name can force an operator to choose between replacing the local asset and omitting the incoming one. That decision belongs in the deployment record rather than in the memory of the person clicking through the conflict screen.

Push Update is the later distribution step for sub-accounts that previously received that snapshot. It sends selected changes from a refreshed snapshot to selected linked sub-accounts inside the same agency. It does not reload the entire snapshot automatically, and it does not push updates to external agencies.

Use Load Snapshot for the first deployment or a deliberate addition. Use Push Update only after refreshing the snapshot and identifying the assets and linked locations that should receive that version.

A snapshot is a manual release pipeline

The source sub-account, snapshot and deployed accounts do not synchronize automatically. Changing a workflow in the source does nothing to the snapshot until an operator runs Refresh Snapshot and selects the added or modified assets. Distribution then requires a separate Push Update.

1. Change and test the asset in the source sub-account.
2. Run Refresh Snapshot.
3. Select the new or modified assets.
4. Review the refresh at asset level.
5. Select the linked destination accounts.
6. Select the exact assets for Push Update.
7. Inspect push and load history.
8. Run destination acceptance tests.

Editing or opening the snapshot does not refresh it and does not distribute anything. Likewise, previous inclusion does not guarantee future distribution. Under Edit Snapshot, the agency independently controls enabled assets and enabled locations. Disabled assets are omitted from later pushes, and disabled locations stop receiving them.

That separation is useful because it supports controlled releases, but it creates two quiet omissions: the operator can refresh the correct asset and fail to select a location, or select the correct location and leave the asset disabled. Record both selections for each rollout.

Version history is evidence, not rollback

Every successful refresh creates a new snapshot version. Version History records the date and time plus Added, Removed and Synced counts compared with the immediately preceding version. Failed refreshes do not create versions.

A version entry does not deploy itself. Version Management does not update sub-accounts, and HighLevel provides no built-in restore or revert to an earlier snapshot version. The version number tells you what snapshot state existed; it does not put a destination back into that state.

There is also no snapshot-level uninstall after deployment. An applied snapshot cannot be unloaded as one unit. If a rollout is wrong, individual assets must be deleted, repaired or replaced manually in each affected sub-account.

Unlinking an asset from the master does not perform that cleanup. It affects future pushes only and leaves previously deployed copies in place. Use unlinking to stop distribution, not to remove an asset from client accounts.

A practical release record should contain the source change, successful snapshot version, selected assets, selected locations, conflict decisions, push result and destination test result. Without that record, version history shows only part of the release.

Refreshes can alter live workflow execution

A refresh is not merely a packaging operation. When a refresh removes a step from a workflow originally created through the snapshot, HighLevel removes contacts waiting on that deleted step so they do not remain stuck. A deleted wait step is the clearest example.

The affected workflow receives a one-time notice, and its Execution Logs record Removed by - Snapshot Refresh. That behavior prevents contacts from waiting on a step that no longer exists, but it also changes active execution. Deleting a workflow step therefore requires an execution-log check before and after the release.

Refreshes also support partial success. If individual assets fail, successful assets continue processing and failed assets are marked for retry. Reaching the end of the refresh process does not prove that every selected asset entered the new version.

Initial creation has a separate risk. Force Create Snapshot saves the assets that loaded successfully and skips failed assets. HighLevel provides a skipped-asset summary, but the resulting snapshot still exists and can look deployable. Force creation is not available during refresh. A snapshot can also be created with no assets selected, producing an empty snapshot that requires a later refresh.

Do not publish a version number to the rollout log until the asset counts, failures and skipped-asset report have been checked.

Verify the deployment at asset level

Snapshot Load History supplies destination-side evidence. From Agency View → Sub-Accounts → select account → Actions → Snapshot actions → View snapshot history, the agency can inspect the snapshot name, last loaded version, type, date, time and initiating user. Opening a load exposes its asset count, categories and statuses such as Success or Processing.

Push Update History starts from the agency snapshot and reports distribution across accounts. It is a different view from the account-level load history, and both are needed: one proves what the agency attempted to distribute; the other records what a particular destination received.

HighLevel’s published Push History page carries a dated warning that a Completed label might still represent only part of a category, such as 5 of 10 funnels. The page does not state that the warning has been resolved. Treat the category count and per-asset detail as stronger evidence than the top-level label.

Failed account loads have a narrow retry path. A retry must occur within 48 hours, and the source snapshot must remain unchanged since the original attempt. Refreshing or modifying the snapshot removes the retry option and requires a new load. Retrying also does not include changes made after the original attempt.

Optional push email reports are sent after completion, not when a push starts or fails midway. An Agency Admin can notify the initiating user and up to five additional Agency Admins. Use those emails as completion summaries and links to Push History, not as real-time monitoring.

For fewer than 10 target locations, HighLevel sends individual progress notifications. At 10 or more, it groups progress at 10%, 30%, 70% and 100%, while still sending an individual alert for each failed push. Large rollout progress is compressed; failure inspection remains account-specific.

Build the master before multiplying it

At five or more sub-accounts, inconsistent foundations create more work than snapshot mechanics. A master containing duplicate fields, ambiguous tags or workflows tied to client-specific assumptions distributes those problems faster.

Define the CRM structure before building the automation layer. Custom Fields and Tagging Conventions You Won't Regret in a Year provides the naming discipline needed to keep conflicts and duplicate structures visible. Then use Building a GoHighLevel Sub-Account From Zero: The Order That Avoids Rework to sequence the source build before turning it into a deployment asset.

Keep destination-specific requirements outside the claim that the snapshot is complete. Domains, platform connections, approvals, phone assignments and excluded customer data belong in a post-load checklist. This makes the handoff honest: the snapshot delivers reusable configuration, while the checklist turns that configuration into an operating sub-account.

External sharing is a separate distribution model

Internal linked sub-accounts receive selected updates through Refresh Snapshot followed by Push Update. Snapshots shared outside the agency are point-in-time clones. Updating the source snapshot does not alter copies that external agencies already imported.

To distribute a later external version, the owner must refresh the snapshot, generate a new share URL and send it to the recipient. Generating the new URL invalidates the previous URL. There is no continuing update relationship between the owner’s snapshot and an already imported external copy.

Label external releases with the corresponding snapshot version and distribution date. Without those two values, the recipient cannot reliably distinguish a current clone from an older import.

What to do

1. Create a four-column rollout checklist for every asset: transferred, excluded, transferred but inactive, and destination test passed.
2. Before snapshot creation, make every required dashboard non-private and explicitly select the default dashboard for the destination.
3. For every existing-account conflict, record Override or Skip by asset before confirming the load; never approve a batch of undocumented overrides.
4. Run Refresh Snapshot first and Push Update second; record the successful version number before selecting destination accounts.
5. After each refresh, inspect every failed or skipped asset and do not release the version while the failed count is above 0.
6. Retry failed account loads within 48 hours and do not modify or refresh the source snapshot until the retry is complete.
7. For pushes to 10 or more locations, inspect each individual failure alert rather than relying on the grouped 10%, 30%, 70% and 100% milestones.
8. After loading, assign Voice AI phone numbers, connect and publish each funnel or website domain, and complete WhatsApp integration and approval before acceptance.

Questions people ask

Do snapshots copy contacts and conversations?

No. Contacts, appointments, conversations, conversation history and messages are excluded. A snapshot is not a customer-record or account-history migration.

Does changing the source sub-account update its snapshot?

No. Run Refresh Snapshot and select the changed assets. Then run Push Update and select the linked sub-accounts that should receive them.

Can a previous snapshot version be restored?

No. Version History is an audit trail without a built-in revert or restore action. Applied snapshots also cannot be unloaded as a unit.

What happens when Override is selected during a conflict?

The conflicting destination asset is replaced by the snapshot version. The override cannot be undone.

Does unlinking an asset remove it from client accounts?

No. Unlinking prevents that asset from participating in future pushes. Copies already deployed to sub-accounts remain in place.

If your agency needs one controlled master, documented release steps and destination testing instead of another copied setup, we build it inside GoHighLevel, hand it over in full, and you own it. Book a 30-minute walkthrough.