Importing a GoHighLevel snapshot does not launch a working client system. Import adds a shared snapshot to the agency-level library. Loading applies selected assets to a specific sub-account. After that, account-specific connections, owners, senders, domains, calendars, references, and test evidence still need review.
Treat the loaded snapshot as a structured starting point, not a production-ready result.
Separate import from load
HighLevel’s current snapshot import guide documents two distinct actions:
- Import the snapshot: sign in to the intended agency, open the share link or email invitation, review the import prompt, name it if needed, and wait for processing to finish.
- Load the snapshot: from Agency View, open the destination sub-account’s Manage Client page, choose Actions → Load Snapshot, select the imported snapshot and assets, review conflicts, and confirm.
An imported snapshot remains at agency level until it is deliberately loaded. A greyed-out imported snapshot is still processing; HighLevel says to wait rather than starting another import.
Before either action, record the source, snapshot name and version, link restrictions, intended agency, intended sub-account, selected asset categories, and person authorized to approve conflicts. A one-time or restricted link can fail for a valid access reason, so do not keep retrying an unexplained error.
Know what can transfer and what cannot
The October 9, 2026 HighLevel snapshot overview lists reusable assets that can be selected, including workflows, triggers, calendars, custom fields, custom values, pipelines, tags, forms, funnels, websites, templates, surveys, dashboards, knowledge bases, and other supported configuration.
It also lists items that do not transfer, including contacts, appointments, conversations, messages, live account activity, Stripe connections, third-party integrations, and some account-specific assignments or approvals. Available categories can vary by enabled features and selection.
| Layer | Snapshot may carry | Still needs destination review |
|---|---|---|
| Structure | Workflows, pipelines, tags, fields, forms, funnels, templates | Correct references, status, ownership, and conflicts |
| Calendars | Calendar assets and groups | Users, availability, external calendar connections, locations, notifications |
| Messaging | Templates and workflow steps | Sending domain, from email, phone eligibility, consent, DND, staff replies |
| Websites and funnels | Pages, forms, surveys, reusable design assets | Production domain, tracking, embeds, links, forms, publishing state |
| Data | Custom fields, custom values, selected objects | Client-specific values and no source-account data leakage |
| Integrations | Some configuration references | Authentication, tokens, payment providers, social accounts, external apps |
| Operations | Workflow logic and tasks | Real staff, permissions, notification settings, and handoff |
This is why “the assets are visible” is not an acceptance test.
Load into a test copy before a live account when practical
For a new implementation, a clean test sub-account makes imported dependencies and source-account assumptions easier to see. For an existing account, HighLevel’s load-snapshot guide allows selective asset loading and conflict review, but an intentional override cannot always be reversed through the snapshot load itself.
Before loading into an account with active data:
- export or document critical current configuration;
- capture the current asset inventory and active workflows;
- identify naming conflicts;
- decide which assets should be skipped, kept alongside, or replaced;
- define the rollback action for each approved change;
- schedule a quiet test period if customer-facing automation could be affected.
We would not use a live client account as the first place to discover what the snapshot contains.
Reconnect account-specific dependencies
Work through this checklist before publishing anything.
Business and user context
- Confirm business name, address, timezone, locale, and approved contact details.
- Create or verify real users and permissions.
- Replace source-account assignees with destination users or queues.
- Check “only assigned data” and pipeline access where used.
- Enable staff notifications required by the workflow.
Calendars and booking
- Confirm each calendar’s owner, team, availability, duration, buffers, location, and timezone.
- Reconnect external Google or Outlook calendars where required.
- Verify reschedule, cancellation, reminder, and confirmation settings.
- Check workflow references to calendar IDs or groups.
- Make a controlled booking, reschedule, cancellation, and no-show test.
Domains, sites, forms, and links
- Connect only approved destination domains.
- Keep test pages unpublished or isolated until acceptance.
- Verify forms and surveys submit to the correct destination records.
- Replace source URLs, booking links, privacy links, webhook endpoints, and redirect targets.
- Check that buttons, forms, and calendars do not point back to the template account.
Email and phone sending
- Reconnect the approved sending domain or provider.
- Verify every From Name, From Email, reply address, and internal recipient.
- Confirm phone-number ownership, routing, A2P or toll-free eligibility, and channel availability.
- Review DND, consent, quiet-hour, and stop rules.
- Keep customer-facing sends disabled until controlled tests pass.
Custom values, fields, and workflow references
- Compare imported custom values with the destination’s required values.
- Search messages and pages for source business names, emails, phones, domains, calendar links, and test text.
- Verify custom-field and opportunity-field references.
- Confirm tags, pipelines, stages, forms, surveys, templates, and workflows referenced by every trigger or action exist.
- Check fallback branches when a referenced item is missing.
Integrations and credentials
- Reauthorize third-party connections in the destination account.
- Replace source webhooks, API references, payment connections, social accounts, and app settings.
- Never store private tokens in handoff documents or reusable snapshot text.
- Test failures safely before enabling production traffic.
Keep the first test isolated
Use plainly labeled test contacts, safe internal inboxes, and non-customer phone numbers. Keep workflows in draft or customer-facing actions disabled until dependencies are complete. If a workflow must be published to test, narrow its trigger to an explicit test marker and remove that marker after acceptance.
A useful order is:
- inventory loaded assets;
- reconnect users, calendars, domains, senders, and integrations;
- review every workflow reference;
- test individual assets;
- test the end-to-end lifecycle;
- remove test data and temporary gates;
- obtain sign-off before publishing or routing live traffic.
Do not test with a real customer’s contact record simply because it already has the right fields.
Inspect every imported workflow before publishing
For each workflow, record:
| Check | Pass evidence |
|---|---|
| Name and purpose | A staff member can explain the workflow’s job and boundary |
| Trigger and filters | Only the intended test event enrolls |
| Re-entry | Repeat behavior matches the lifecycle rule |
| Users and assignments | Destination users or queues are selected |
| Calendars and pipelines | Every referenced item exists and is correct |
| Messages and senders | Source branding and addresses are gone; test reaches only approved recipients |
| Waits and timezones | Timing matches the destination account |
| Suppression and exits | Replies, bookings, DND, cancellations, or state changes stop the right steps |
| Webhooks and integrations | Destination endpoint and failure handling are verified |
| Publish state | The workflow remains gated until all dependencies pass |
If a workflow fails, diagnose Enrollment History and Execution Logs before replacing it. GoHighLevel workflow not triggering? provides a symptom-led order for that review.
Run a clean-account acceptance matrix
The matrix should cover the normal path, changed state, repeat event, exception, and human handoff. Example scenarios should be rewritten for the actual project rather than copied as universal requirements.
| Scenario | Expected record/state | Expected automation | Evidence |
|---|---|---|---|
| First valid form submission | One contact and one intended opportunity | Correct acknowledgement and assignment | Form record, contact, opportunity, execution |
| Repeat submission | Update or new record according to the approved identity rule | No unintended duplicate message or card | IDs, timestamps, branch taken |
| Customer replies during wait | Reply state becomes current | Generic follow-up stops or changes | Conversation and workflow exit |
| Appointment booked | Booking and pipeline state align | Pre-booking follow-up stops | Appointment, stage, execution |
| Appointment changes | Current booking is authoritative | Old reminder path stops | Status and message timeline |
| DND or missing consent | Record remains visible | Prohibited send is suppressed | Contact settings and logs |
| Missing assignee or calendar | Exception is visible | Workflow does not guess silently | Failure branch, task, or alert |
| Integration unavailable | No false success state | Retry or human recovery follows the design | Error and owner evidence |
How to test a GoHighLevel lead workflow before launch explains how to record starting conditions, expected results, actual evidence, defects, and sign-off.
Use the verified clean-account work without overstating it
Edex completed an anonymized clean-account snapshot implementation that combined a three-page funnel, eight-stage pipeline, and seven canonical workflows. The work included duplicate prevention, suppression and exit logic, reusable deployment, and handoff. All 23 documented QA scenarios passed at the recorded acceptance point.
That is evidence that Edex has implemented and accepted a coordinated system in a clean account. It is not evidence that a snapshot can be loaded unchanged into every account, that every imported asset is automatically connected, or that the system remained permanently error-free. The public funnel, pipeline, and QA case study preserves those limits.
Define rollback and handoff before launch
The release owner should have:
- the snapshot name and version;
- the selected asset inventory;
- a list of conflicts and decisions;
- destination-specific connections and owners;
- the workflow publish-state register;
- completed test evidence and unresolved defects;
- rollback or disable steps;
- staff operating instructions;
- known limitations and future update rules.
Set a no-launch threshold. Any unresolved customer-facing sender, live trigger, missing owner, broken calendar, source-account reference, or failed critical scenario should block release.
Snapshots make reuse possible. The import checklist is what makes reuse accountable.