Designate one sub-account as your template, then clone its setup into every new client sub-account in a single step.
Loading the guide...
Did this answer your question?
Help us make the guides more useful.
0 helpful · 0 not helpful
Designate one sub-account as your template, then clone its setup into every new client sub-account in a single step.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
Snapshots let you build a client setup once and reuse it. You designate one sub-account as your agency's snapshot, and new sub-accounts can be created already carrying its pipelines, templates, forms, products, tags, and folder structure instead of starting empty.
If you are coming from GoHighLevel, this is the same idea as a snapshot, with some real differences worth knowing before you plan around it. Those are listed at the bottom of this page.
Build one sub-account the way you want every new client to start. Pipelines, email templates, forms, products, tags, snippets, whatever your standard setup includes.
In the agency admin, open that sub-account's menu and choose Designate as Snapshot. One sub-account per agency is designated at a time.
The preview action and the Initialize from snapshot choice appear only after a sub-account has been designated. If you do not see them, check that your agency has selected its snapshot source first.
Choose Preview snapshot contents to see exactly what the clone would carry across, table by table, with a row count for each. This is a read-only view. Nothing is written until you actually create or refresh a sub-account.
The sample above has 11 rows across five table types. Your own preview will reflect the content in your designated source sub-account.
Preview before you rely on a snapshot in front of a client. It is the fastest way to catch a setup that lives in a place the clone does not cover.
When creating a new sub-account, tick Clone from snapshot under "Initialize from snapshot". The new sub-account is created with the snapshot's content already in place.
Cloning and the default starter content are mutually exclusive. If you clone, you get the snapshot's setup instead of the built-in defaults, so you do not end up with two of everything.
Refresh from snapshot re-applies the current snapshot to a sub-account that already exists. Use it when you improve your standard setup and want an existing client brought up to it.
⚠️ Refresh replaces, it does not merge, and it is not safe on a sub-account with live work in it. Every piece of cloneable content in the target is deleted and re-cloned from the snapshot. That includes its pipelines and stages, and its custom field definitions. No customer record is deleted, but the records that referenced the deleted rows are stranded: existing opportunities point at pipeline stages that no longer exist, and answers collected under a custom field stop being visible until a field of that name exists again. Treat refresh as a reset for a sub-account you are willing to rebuild, not as a routine sync, and preview first.
The clone works from an explicit registry of table types. It is default-deny, so anything not on that list is not copied, and a new table added to the product has to be classified before it can ship. The preview dialog is the authoritative list for your own install, because it reports exactly what would be copied and what would be skipped.
Sales and pipeline
Automation and forms
Content and templates
Catalog and commerce
Organization and settings
Foreign keys are rewritten as part of the clone, so a workflow that points at a list, a template, a pipeline stage, or a form ends up pointing at the copy in the new sub-account rather than back at the snapshot.
All customer data. Contacts, companies, notes, conversations, messages, attachments, deals, invoices, payments, estimates, and documents stay in the sub-account they belong to. A snapshot is a setup template, not a data copy.
Credentials and tenant-bound IDs. Connected accounts and per-tenant external identifiers are not carried over. Where a cloneable record embeds one, the field is reset rather than copied. Forms are the clearest example. The form definition comes across, but its Google Ads conversion action, Meta CAPI, and GA4 tracking settings are reset so the new sub-account binds its own rather than reporting into the snapshot's ad account. Workflow drafts arrive without an Inbound Webhook Endpoint URL or Signing Secret, and without the record of when a scheduled workflow last ran. A copy gets its own URL when you save it; create its secret with the regenerate button next to Signing Secret.
Active workflows. Only workflow drafts are cloned. A workflow that is live in the snapshot sub-account is deliberately excluded, so cloning cannot quietly start sending on behalf of a brand new client. Build the workflows you want cloned as drafts in the snapshot, then activate them in the new sub-account once you have checked them.
Booking setup. Calendars are not copied, because a calendar is bound to the people and connected accounts of its own sub-account. Appointment types, services and service categories are not copied either, for the same reason: each one belongs to a calendar, so without the calendar there is nothing to attach them to. Expect to rebuild booking setup in the new sub-account. The preview dialog says so too, and reports these as skipped rather than silently copying nothing.
Workflow templates. The template gallery is not stored per sub-account, so the clone has no way to scope it and skips it. The preview dialog lists it as skipped and names it as a limitation of the clone. Workflow drafts are copied, as above.
Worth reading if you are planning a migration around this.
Because you own the source, none of these are fixed. The clone registry is one file that lists each table and how it should be treated, so extending what a snapshot covers is a code change you are able to make.