Go High Level Snapshots Deep Dive: Features & Uses | GHLCRM.US

Go High Level Snapshots are reusable templates that capture selected configuration and assets from a HighLevel sub-account so agencies can deploy proven setups across other sub-accounts without rebuilding everything manually.

A snapshot can include assets such as:

Workflows

Funnels

Calendars

Forms

Campaigns

Custom Fields

and many other supported configuration elements.

The basic architecture is:

Build Source Sub-Account

→ Test Configuration

→ Create Snapshot

→ Deploy to Another Sub-Account

→ Customize

→ QA

→ Launch

But modern HighLevel Snapshots go further.

Agencies can now:

Create

Load

Share

Import

Refresh

Push Selected Updates

Protect Assets

Use Snapshots in SaaS Plans

and:

Sell Snapshots through the HighLevel Marketplace

HighLevel's current documentation explicitly describes snapshots as reusable templates for copying account assets quickly while preserving standardized configurations across deployments.

For a broader introduction and related snapshot resources, see our GoHighLevel Snapshots hub.

Start Your GoHighLevel 30-Day Free Trial →

A GoHighLevel Snapshot is a reusable copy of supported configuration from a source sub-account.

The important word is:

Configuration

A snapshot is designed primarily to reproduce how an account is built.

It is not intended to duplicate the live business history inside the account.

HighLevel's current documentation describes snapshots as a way to capture configuration from a sub-account—including workflows, funnels, calendars, forms, campaigns, custom fields, and other supported assets—and reuse that setup elsewhere.

A common misunderstanding is:

Build Snapshot

↓

Build System Inside Snapshot

That is not the normal process.

Instead:

Create / Use Source Sub-Account

↓

Build System

↓

Test System

↓

Create Snapshot From That Sub-Account

HighLevel specifically notes that users do not build a snapshot directly; they build the source account first and then create the snapshot from it.

This distinction is important for agency workflow.

Imagine a construction company.

A blueprint contains:

Structure

Layout

Specifications

It does not contain:

The People Living in the House

Their Conversations

Their Personal History

HighLevel Snapshots work similarly.

They are closer to:

Account Blueprint

than:

Account Backup

This is one of the most important distinctions.

Designed for:

Reuse

Replication

Standardization

Deployment

Would imply:

Historical Recovery

Live Data Preservation

Point-in-Time Restoration

A HighLevel Snapshot should not be treated as a complete disaster-recovery backup.

The exact supported asset list evolves as HighLevel adds functionality.

Current documentation identifies broad categories such as:

Workflows

Funnels

Calendars

Forms

Campaigns

Custom Fields

and additional account configuration.

Modern snapshots can also support newer HighLevel assets depending on feature support and selection.

The key principle is:

Snapshot = Supported Selected Assets

not:

Everything Inside the Account

Agencies do not necessarily need to capture the entire source account.

HighLevel supports selective asset control when creating snapshots, allowing users to include all supported assets or select only what is needed.

For example:

Include:

Pipelines

Workflows

Forms

Calendars

Funnels

Custom Fields

and other required configuration.

Include primarily:

Workflows

and their relevant dependencies.

Include:

Funnels

plus supporting assets.

This makes snapshots useful beyond full account cloning.

A snapshot should not be assumed to contain every form of live business data.

HighLevel's documentation around snapshot-enabled AI assets explicitly clarifies that snapshots do not transfer live records such as:

Contacts

Conversation History

Messages

and:

Live Data.

That distinction should guide the entire implementation strategy.

Consider a roofing agency template.

The source account may contain:

John Smith

Jane Doe

Acme Property Management

Those contacts belong to the source business.

When deploying the roofing system to another client:

Workflow Architecture

may be reusable.

The original customer's:

Contacts

are not.

That separation is both operationally and logically necessary.

The same principle applies to:

Messages

Past Conversations

and:

Historical Interactions

A snapshot is intended to recreate supported system configuration.

It is not intended to reproduce another client's historical conversations.

The modern snapshot lifecycle can be understood as:

Source Account

↓

Create

↓

Snapshot Library

↓

Then choose:

Load

Share

Import

New Sub-Account Deployment

SaaS Provisioning

or:

Marketplace Distribution

Later:

Source Changes

↓

Refresh Snapshot

↓

Push Selected Updates

This lifecycle is more sophisticated than simply “copy account.”

HighLevel's current snapshot overview separately defines Create, Load, Create New Sub-Account, Share, Import, Refresh, Push Updates, View Assets, and Manage Linked Assets.

These terms should not be confused.

Captures supported selected assets from a source sub-account.

Applies selected snapshot assets to an existing sub-account.

Adds a snapshot shared by someone else to your agency-level snapshot library.

Updates an existing snapshot using current selected assets from its source sub-account.

Deploys refreshed snapshot changes to eligible linked sub-accounts.

These are separate operations.

The practical process begins with a properly configured source account.

Create:

Pipelines

Workflows

Forms

Funnels

Calendars

Fields

and other required assets.

Do not snapshot an untested system.

Test:

Lead Entry

Workflow Paths

Appointments

Notifications

Exit Conditions

Forms

and:

Dependencies

From Agency View, create a snapshot from the source sub-account and select the assets you want to capture.

HighLevel's current snapshot creation process supports both broad and selective asset capture.

A snapshot amplifies whatever is inside the source account.

If the source contains:

Poor Naming

Broken Workflows

Duplicate Fields

Unused Funnels

Bad Logic

then the snapshot reproduces those problems.

The correct process is:

Build

↓

Clean

↓

Test

↓

Document

↓

Snapshot

not:

Build Quickly

↓

Snapshot Everything

Once a snapshot exists, selected assets can be loaded into another sub-account.

This allows:

Existing Sub-Account

Snapshot

↓

Reusable Configuration Added

HighLevel treats loading as distinct from importing: importing brings the snapshot into the agency's library, while loading applies its assets to a sub-account.

Snapshots can also be used when creating new client environments.

Conceptually:

New Client

↓

Create Sub-Account

↓

Apply Snapshot

↓

Configure Client-Specific Information

↓

QA

↓

Launch

This is one of the strongest agency use cases.

Loading the snapshot is the beginning of client configuration.

It is not necessarily the end.

A client may still require:

Business Information

Users

Domains

Email

Phone

Calendars

Integrations

Custom Values

Offers

Branding

Permissions

and:

Workflow Validation

Treat snapshot deployment as:

Pre-Built Foundation

not:

Instant Finished Client Account

Suppose an agency specializes in roofing.

The master system might include:

New Roofing Lead Pipeline

Estimate Workflow

Appointment Reminder

No-Response Follow-Up

Review Request

Lead Form

Landing Page

and:

Internal Notifications

The agency creates:

Roofing Master Snapshot

Then every new client starts with:

Roofing Master Snapshot

↓

Client Information

↓

Client Branding

↓

Calendar Configuration

↓

Communication Setup

↓

Offer Customization

↓

QA

↓

Launch

This can save substantial repetitive work.

A dental template might contain:

New Patient Inquiry

↓

Administrative Qualification

↓

Appointment

↓

Reminder

↓

Follow-Up

↓

Review Request

The snapshot can reproduce the marketing and administrative architecture.

It should not be treated as replacing specialist clinical systems or professional healthcare workflows where those are required.

A reusable HVAC architecture could include:

New Lead

↓

Service Type

↓

Contact

↓

Appointment

↓

Estimate

↓

Won / Lost

↓

Review

The snapshot provides the framework.

Each HVAC company still receives its own:

Brand

Team

Contact Information

Calendars

Service Areas

and:

Business Rules

A marketing agency might build a reusable system containing:

Lead Capture

Discovery Call Calendar

Sales Pipeline

Proposal Follow-Up

Client Onboarding

and:

Review Workflow

The same internal system can then be adapted across client-facing or agency-owned accounts.

The biggest advantage is not merely speed.

It is:

Consistency

Without snapshots:

Workflow built one way.

Workflow built differently.

Different naming.

Different fields.

Eventually:

Support Becomes Difficult

With a standardized template:

Master Architecture

↓

Controlled Deployment

↓

Client-Specific Customization

This reduces configuration drift.

Agencies that rely heavily on snapshots should consider maintaining a clean master environment.

For example:

MASTER – Roofing

MASTER – Dental

MASTER – HVAC

MASTER – Real Estate

The master account should be used primarily for:

Development

Testing

Standardization

and:

Snapshot Creation

rather than everyday client operations.

If you create a snapshot from an active client account, you may accidentally include:

Client-Specific Assets

Old Tests

Unnecessary Fields

Legacy Workflows

or:

Brand-Specific Configuration

A dedicated master reduces contamination.

Use descriptive names.

Instead of:

Snapshot 1

New Snapshot

Copy Final

consider:

ROOFING – Lead Gen Core – v1

DENTAL – New Patient System – v2

AGENCY – Client Onboarding – v3

A useful pattern is:

[NICHE] – [PURPOSE] – [VERSION]

This makes larger libraries easier to manage.

Creating a snapshot does not establish automatic live synchronization with the source account.

This is critical.

Suppose:

Monday

Snapshot created.

Then:

Friday

you add:

New Workflow

Updated Form

Improved Funnel

to the source account.

The existing snapshot does not automatically absorb those changes.

HighLevel's current documentation explicitly states that source-account changes do not automatically update an existing snapshot. The snapshot must be manually refreshed.

The process is:

Source Sub-Account Updated

↓

Agency View

↓

Account Snapshots

↓

Select Snapshot

↓

Refresh

↓

Choose New / Modified Assets

↓

Complete Refresh

HighLevel then loads those selected assets from the source account into the snapshot.

Modern HighLevel snapshot refreshes are more resilient than an all-or-nothing process.

If some selected assets fail to load:

Successful Assets Continue

while:

Failed Assets Are Identified

The user can retry only the failed assets rather than restarting the complete refresh.

This becomes particularly useful for large snapshot libraries.

Refreshing updates the snapshot itself.

It does not mean every client account automatically changes.

After refresh, eligible updates can be pushed.

The model is:

Source Account

↓

Refresh Snapshot

↓

Updated Snapshot

↓

Push Update

↓

Selected Linked Sub-Accounts

This separation gives the agency more control.

HighLevel's Push Update capability allows refreshed snapshot assets to be sent to sub-accounts that previously imported the snapshot within the agency.

The agency can select:

Which Sub-Accounts

and:

Which Assets

to update.

For example:

Master Snapshot Updated

↓

Select:

Workflow A

Form B

↓

Push to:

Client 1

Client 3

Client 8

rather than updating every asset in every account.

This is a major distinction.

The process does not necessarily require:

Reload Entire Snapshot

Instead:

Choose Relevant Update

↓

Choose Destination Accounts

↓

Push

HighLevel describes these updates as selective rather than inherently destructive, with existing account data remaining in place.

Modern snapshot management also includes linked assets.

Linked assets help determine which snapshot-derived assets remain associated for future update pushes.

This becomes important because an agency may intentionally customize a snapshot asset after deployment.

Not every local asset should necessarily continue receiving master changes.

HighLevel's current snapshot overview explicitly includes Manage Linked Assets as part of the snapshot lifecycle.

Imagine:

Master Workflow

is deployed to 50 clients.

Client 12 requires unique logic.

You customize its workflow.

Later:

Master Workflow Changes

You now need to decide:

Should Client 12 receive the master update?

This is why snapshot governance matters.

Snapshots can standardize deployment.

They do not eliminate architecture decisions.

There is another important limitation.

HighLevel's current refresh documentation states that Push Updates operate for sub-accounts within the agency.

External agencies do not receive the same internal push mechanism; they need to re-import through the appropriate updated sharing flow.

Therefore:

Same Agency

→ Controlled push capability.

External Agency

→ Distribution/import process.

Do not assume a shared snapshot creates permanent live synchronization across independent agencies.

HighLevel provides push history so agencies can review snapshot update deployments.

The history can show:

Successful Sub-Accounts

Failed Sub-Accounts

Pending Sub-Accounts

and:

Asset-Level Details.

This is important when managing large deployments.

HighLevel also supports rolling notifications for larger snapshot pushes.

For pushes to 10 or more sub-accounts, notifications are grouped around progress milestones such as:

10%

30%

70%

and:

100%

while failures can still generate individual alerts.

This is a small feature operationally, but it illustrates how snapshots are increasingly designed for larger-scale agency deployment.

Snapshot updates can affect active workflows.

HighLevel now includes handling for contacts waiting on workflow steps that are removed through snapshot refresh.

If a refreshed snapshot removes a workflow step that had waiting contacts, HighLevel can remove those contacts from the deleted step and record the event in execution logs.

This reduces the risk of contacts remaining indefinitely stuck on a workflow step that no longer exists.

Still:

Snapshot Update

should always be treated as a production change.

For important deployments:

Master Update

↓

Refresh Snapshot

↓

Test Account

↓

QA

↓

Small Client Batch

↓

Monitor

↓

Broader Push

This is safer than:

Change

↓

Push to 100 Clients Immediately

The larger the deployment, the more valuable controlled rollout becomes.

Snapshots can also be shared.

HighLevel's current sharing system allows agencies to distribute reusable configurations through controlled sharing mechanisms.

The recipient can then:

Receive Access

↓

Import Snapshot

↓

Load Snapshot

These are separate actions.

Again:

Makes the snapshot available to a recipient.

Adds the shared snapshot to the recipient's agency snapshot library.

Applies selected assets to an actual sub-account.

HighLevel explicitly separates these three concepts.

Sharing can work for:

Partner Agencies

Consultants

Clients

Implementation Teams

Template Distribution

and:

Commercial Snapshot Products

The correct sharing model depends on who should control and reuse the assets.

HighLevel also provides asset protection capabilities for snapshot creators.

This matters when a snapshot contains proprietary:

Workflows

Funnels

Automation Architecture

or:

Other Valuable Configuration

HighLevel's current sharing system includes Assets Protection options designed to help control high-value snapshot assets.

Imagine an agency spends months creating:

Niche CRM Architecture

Workflow Logic

Funnels

Forms

Automation

Then sells the template.

Without appropriate protection:

Buyer

↓

Copies

↓

Repackages

↓

Resells

HighLevel's Marketplace snapshot system includes IP Protection specifically to reduce unauthorized repackaging and resale.

Snapshots are no longer only internal agency tools.

HighLevel allows eligible creators to list snapshots through its App Marketplace.

The current Marketplace system supports monetizing snapshot configurations and distributing them to other HighLevel users.

This creates a product model:

Expertise

↓

Reusable Configuration

↓

Snapshot

↓

Marketplace Product

↓

Buyer

↓

Deployment

An agency can therefore productize implementation knowledge.

HighLevel's current Marketplace documentation describes pricing models including:

One-Time

Monthly

and:

Yearly Subscription

depending on the listing configuration.

That creates several business models.

Customer buys once.

Customer pays recurring access according to Marketplace configuration.

Sell the template, then offer:

Setup

Customization

Training

or:

Support

as additional services.

Marketplace snapshot products can also distinguish distribution models.

Current HighLevel documentation describes options where the product is charged at:

Agency

or:

Sub-Account

level depending on distribution configuration.

This matters when designing commercial snapshot products.

Marketplace snapshot listings can also be configured around:

Standard

or:

White-Label

distribution models.

HighLevel describes white-label listings as removing visible branding to increase usability across different HighLevel customers.

This can make sense for agencies selling infrastructure to other agencies.

Do not sell:

“500 Workflows!”

simply because a large number sounds impressive.

A better product is:

Specific Problem

↓

Specific Niche

↓

Specific System

For example:

Roofing Lead Follow-Up System

is easier to understand than:

Ultimate Mega Automation Snapshot

Product clarity matters.

HighLevel also allows Marketplace snapshots to be attached to SaaS plans.

When configured appropriately, the selected snapshot can be automatically included when a new client purchases the SaaS plan and a new sub-account is provisioned.

This creates:

Customer Purchases SaaS Plan

↓

Sub-Account Created

↓

Snapshot Applied

↓

Pre-Built System Available

↓

Onboarding

This is one of the strongest scalability use cases.

These are different workflows.

Manual distribution:

Share

↓

Import

↓

Load

Automated:

Purchase SaaS Plan

↓

Sub-Account Provisioned

↓

Attached Snapshot Applied

HighLevel explicitly distinguishes snapshot sharing from SaaS provisioning.

Suppose an agency sells:

HVAC Growth OS

The package includes:

CRM

Lead Pipeline

Follow-Up

Appointment Workflow

Review System

Forms

Landing Pages

and:

Automation

The customer purchases:

HVAC Growth OS

↓

HighLevel creates:

New Sub-Account

↓

Snapshot applies:

HVAC System

↓

Agency configures:

Business Data

↓

Client launches.

This is much more scalable than building every client from zero.

The broader progression is:

Custom Service

↓

Repeated Delivery

↓

Standardized Process

↓

Master Account

↓

Snapshot

↓

Productized Service

↓

SaaS / Marketplace Product

Snapshots therefore sit at the intersection of:

Agency Services

and:

Software-Like Delivery

Snapshots are strongest when:

Clients Share Similar Requirements

Processes Are Repeatable

Configuration Is Standardized

Agency Has Clear SOPs

and:

Customization Is Predictable

Examples:

Roofing Agencies

Dental Marketing

HVAC Marketing

Real Estate

Coaching

Consulting

Local Service Businesses

and:

Internal Agency Operations

Snapshots are less valuable when every client has:

Completely Different Architecture

Different Systems

Unique Data Models

Complex Custom Integrations

and:

Highly Specialized Processes

You can still use partial snapshots.

But attempting to force every client into one giant template may create more work than it saves.

One alternative is modularization.

Instead of:

ONE MASSIVE SNAPSHOT

create reusable components such as:

Lead Generation Core

Appointment System

Review System

Client Onboarding

Reactivation

Sales Pipeline

Then deploy the combination appropriate for the client.

This reduces unnecessary assets.

Another model is:

Agency Core

Industry Layer

Client Customization

For example:

Standard naming, notifications, tracking.

Roofing pipeline and workflows.

Specific branding, offers, users, calendars.

This creates a more maintainable architecture.

Because snapshots can evolve, agencies should use basic version discipline.

For example:

ROOFING – CORE – v1.0

↓

v1.1

Minor workflow improvements.

↓

v2.0

Major architecture change.

Document:

What Changed

Why

Which Clients Received It

When

and:

Whether QA Passed

HighLevel provides push history, but your internal documentation should still explain business-level changes.

Added: No-response branch.

Changed: Appointment reminder timing.

Fixed: Incorrect opportunity movement.

Added: Review request.

Changed: Form field mapping.

This is far easier to manage than:

Snapshot Final

Snapshot Final New

Snapshot Final Final

For larger agencies, define:

Snapshot Owner

Source Account

Naming Standard

Version

Testing Process

Push Approval

Client Exceptions

Linked Asset Policy

and:

Rollback / Recovery Plan

Snapshots should be treated as production infrastructure.

Not every team member needs permission to create, share, import, or push snapshots.

HighLevel has granular snapshot permissions, and current snapshot-enabled features also distinguish permissions such as:

Create Snapshots

and:

Share / Import Snapshots.

Limit high-impact permissions appropriately.

Before sharing:

Remove Unnecessary Client-Specific Assets

Review Branding

Review Custom Values

Review Integrations

Check Credentials

Inspect Workflows

Review Protected Assets

Test Share / Import

Do not assume a snapshot is safe to distribute merely because it loads correctly.

Some integrations require account-specific credentials or reauthentication after snapshot deployment.

HighLevel's snapshot documentation notes limitations around certain third-party licenses and account-specific configurations.

Therefore:

Snapshot Loaded

does not necessarily mean:

Every Integration Is Live

Always validate:

API Keys

OAuth Connections

External Apps

Domains

Phone

Email

and:

Payment Connections

after deployment.

HighLevel's snapshot overview also notes that WhatsApp usability can depend on Meta approval after import.

That means a template may contain supported configuration, but account-specific approval requirements can still remain.

This illustrates a broader rule:

Configuration Can Be Reused

but:

External Authorization May Still Be Account-Specific

HighLevel's snapshot ecosystem continues expanding into newer platform features.

The current snapshot documentation library includes support guidance for assets such as Voice AI configurations and Agent Studio agents.

For agencies building AI-heavy systems, this makes snapshot architecture increasingly relevant.

But newer assets should always be tested after deployment because they may depend on:

Knowledge Sources

Phone Configuration

Account Credentials

Calendar Relationships

or:

External Services

HighLevel currently supports cloning and sharing Agent Studio AI agents through snapshots.

The documentation also clarifies that:

Contacts

Conversation History

Messages

and:

Live Data

are not transferred as part of that snapshot process.

This reinforces the configuration-versus-data distinction.

Before creating a production snapshot, verify:

Workflows

Triggers

Actions

Waits

Exit Conditions

Pipelines

Forms

Funnels

Calendars

Custom Fields

Custom Values

Notifications

Integrations

Branding

Permissions

and:

Naming

Then test the snapshot itself in a clean account.

This is important.

A snapshot may appear correct in its source because the source already contains dependencies.

A clean destination exposes missing dependencies.

Test:

Create Clean Account

↓

Load Snapshot

↓

Configure Required Account Data

↓

Run Realistic Test Lead

↓

Check Workflow

↓

Check Calendar

↓

Check Pipeline

↓

Check Notifications

↓

Check Integrations

Only then consider wider deployment.

Ask:

Does Workflow A depend on Field B?

Does Funnel A depend on Form C?

Does Calendar A depend on User D?

Does Automation depend on an external integration?

The more dependencies a system has, the more important deployment documentation becomes.

Every production snapshot should ideally include internal documentation describing:

Purpose

Target Niche

Source Account

Included Assets

Required Configuration

Required Integrations

Testing Steps

Known Limitations

Version

and:

Owner

This reduces institutional knowledge risk.

Without standardization:

New Client

↓

Build CRM

↓

Build Pipeline

↓

Build Workflows

↓

Build Forms

↓

Build Calendar

↓

Test

every time.

With snapshots:

New Client

↓

Deploy Tested Foundation

↓

Configure

↓

Customize

↓

QA

↓

Launch

This shifts the team's effort from repetitive construction toward client-specific work.

Suppose an agency previously needs:

12 Hours

to create a standard system.

After building a tested snapshot:

Deployment + Customization = 3 Hours

The agency has potentially saved:

9 Hours

per comparable client.

For 20 similar clients:

9 × 20 = 180 Hours

This is an illustrative example, not a guaranteed outcome.

The actual savings depend on complexity and implementation quality.

A dangerous agency metric is:

How Fast Can We Launch?

A better combination is:

Deployment Speed

Error Rate

Customization Quality

Client Outcome

A snapshot that launches in 20 minutes but requires days of repair is not efficient.

Standardization creates leverage.

But it also creates responsibility.

If one master snapshot supports:

100 Client Accounts

then a poorly tested master update can affect a large deployment.

As scale increases:

Testing Discipline Must Increase

not decrease.

For significant updates, consider:

Development Master

↓

Snapshot Refresh

↓

Internal Test Account

↓

QA

↓

Pilot Clients

↓

Monitor

↓

Broader Push

This mirrors software release management.

Suppose you modify:

Lead Follow-Up Workflow

Do not assume every client wants the same new behavior.

Some may have:

Different Offers

Different Timing

Different Sales Teams

Different Compliance Requirements

or:

Custom Logic

Before pushing:

Segment Clients

You might maintain:

Core Clients

Customized Clients

Legacy Clients

SaaS Clients

Then determine update policy for each group.

This is more sustainable than assuming every account remains identical forever.

Snapshots reproduce supported configuration.

They are not complete historical account backups.

Changes to the source account do not automatically update the existing snapshot.

Refresh is required.

Refresh updates the snapshot.

A separate push process is used for eligible linked sub-accounts.

Internal snapshot pushes and external sharing are different.

External recipients may need an updated import/distribution process.

A messy source creates a messy reusable template.

Clean the master first.

Loading successfully does not prove the business system works.

Test actual customer journeys.

Without versions, teams cannot reliably determine which clients use which architecture.

If every client receives extensive custom changes, future master updates become harder.

Decide what is:

Core

versus:

Client-Specific

The opposite is also dangerous.

Do not force a generic template onto a business whose process genuinely differs.

A marketplace buyer does not necessarily want:

More Workflows

They want:

A Better Solution

Productize outcomes rather than asset counts.

A mature model might be:

Development

↓

Master Sub-Account

↓

QA

↓

Snapshot

↓

Version

↓

Test Deployment

↓

Client Deployment

↓

Client Customization

↓

Production QA

↓

Monitor

↓

Master Improvement

↓

Refresh

↓

Controlled Push

This creates a repeatable development lifecycle.

Agencies can measure:

Average Deployment Time

Configuration Errors

Support Tickets After Launch

Percentage of Standard vs Custom Assets

Update Failure Rate

and:

Time Saved per Deployment

This helps determine whether the snapshot strategy is actually improving operations.

No.

Snapshots are most useful when the agency has repeatable HighLevel implementations.

If every project is completely unique, a full niche snapshot may offer limited benefit.

However, even custom agencies may benefit from smaller reusable modules such as:

Internal Notifications

Review Workflows

Appointment Reminders

or:

Agency Onboarding Systems

Not necessarily.

Create a separate niche snapshot when the industry has meaningfully different:

Pipeline

Customer Journey

Forms

Workflows

Calendars

or:

Offer Structure

Do not create separate snapshots merely because the client industry name changed.

There is no ideal number.

A useful rule is:

Maintain only snapshots that have a clear purpose, owner, source, and deployment use case.

Twenty well-governed snapshots can be better than 200 abandoned templates.

Snapshots are part of the broader HighLevel agency environment rather than a separate base subscription plan.

HighLevel's current core plans are:

Starter currently includes three sub-accounts.

Unlimited includes unlimited sub-accounts.

Agency Pro adds capabilities including SaaS Mode and automated sub-account creation.

For small-scale testing:

Starter

can provide access to a limited number of sub-accounts.

For agencies deploying systems across many clients:

Unlimited

is structurally more relevant because of unlimited sub-accounts.

For agencies building SaaS-oriented provisioning:

Agency Pro

becomes particularly relevant because it includes:

SaaS Mode

and:

Automated Sub-Account Creation.

Choose the plan based on the business architecture.

HighLevel's current public pricing page advertises a standard:

14-Day Free Trial

for Starter, Unlimited, and Agency Pro.

Promotional and partner routes can have different terms, so confirm the offer shown during signup.

Explore GoHighLevel With a 30-Day Free Trial →

A GoHighLevel Snapshot is a reusable template containing supported configuration and selected assets from a source sub-account so the setup can be reused elsewhere.

Snapshots can include supported assets such as workflows, funnels, calendars, forms, campaigns, custom fields, and other configuration available through the snapshot system.

No. Snapshots are intended for configuration rather than transferring live contact databases. Current HighLevel snapshot documentation explicitly excludes contacts from supported live-data transfer.

No. Conversation history, messages, and other live data are not transferred as part of the snapshot model described in HighLevel's current documentation.

No. A snapshot should be treated as a reusable configuration template, not a complete historical backup or disaster-recovery system.

No. HighLevel explicitly states that an existing snapshot does not automatically update when its source sub-account changes. You need to refresh the snapshot.

Refresh loads selected new or modified assets from the source sub-account into the existing snapshot.

No. Refresh updates the snapshot. Eligible linked sub-accounts can then receive selected updates through the Push Update process.

Push Update allows an agency to send selected refreshed snapshot assets to selected linked sub-accounts that previously received the snapshot within that agency.

HighLevel's current Push Update process allows asset selection, so agencies can push selected changes rather than necessarily reloading the complete snapshot.

The normal internal Push Update mechanism applies to linked sub-accounts within your agency. HighLevel says external agencies need to use the appropriate re-import/share process for updated snapshots.

Yes. HighLevel provides snapshot push history showing successful, failed, and pending deployments with asset-level details.

Yes. HighLevel supports controlled snapshot sharing, after which recipients can import the snapshot and load its assets into appropriate sub-accounts.

Sharing gives a recipient access to a snapshot. Importing adds the shared snapshot to the recipient's agency-level snapshot library. Loading then applies selected assets to a sub-account.

Yes. HighLevel provides asset-protection capabilities for snapshot creators and Marketplace distribution.

Yes. HighLevel currently allows snapshot creators to distribute and monetize snapshots through its App Marketplace.

HighLevel's current Marketplace documentation supports multiple pricing approaches, including one-time, monthly, and yearly models depending on the listing configuration.

Yes. Marketplace snapshots can be attached to eligible SaaS plans and automatically included when new client accounts are provisioned through those plans.

No. Sharing involves distribution, import, and loading. SaaS provisioning can automatically apply an attached snapshot when a SaaS purchase creates the new sub-account.

HighLevel's current snapshot ecosystem supports newer assets including Agent Studio agents, subject to the applicable configuration and dependencies.

Not necessarily. Some third-party services, licenses, credentials, authorizations, and account-specific connections may require reauthentication or configuration after deployment.

You can, but a clean master sub-account is usually easier to govern because it reduces the risk of including unnecessary client-specific configuration.

It depends on the deployment model. Full niche snapshots work well for standardized client systems, while modular snapshots can be more flexible when clients need different combinations of functionality.

Load it into a clean test sub-account, configure required account-specific information, run realistic customer journeys, test workflows and dependencies, and verify integrations before deploying it broadly.

Current public pricing is $97/month for Starter, $297/month for Unlimited, and $497/month for Agency Pro.

Unlimited is often structurally useful for agencies because it includes unlimited sub-accounts. Agency Pro becomes more relevant when the business also needs SaaS Mode and automated sub-account creation.

Go High Level Snapshots become much more powerful when they are treated as an agency deployment system rather than simply a copy button.

The basic model is:

Build Once

↓

Test

↓

Snapshot

↓

Deploy

↓

Customize

↓

QA

↓

Launch

But a mature agency extends that into:

Master Sub-Account

↓

Documented Architecture

↓

Snapshot Version

↓

Controlled Deployment

↓

Client-Specific Configuration

↓

Production QA

↓

Master Improvements

↓

Refresh Snapshot

↓

Test Update

↓

Selective Push

↓

Monitor

HighLevel's current snapshot system supports this more advanced lifecycle through separate actions for creating, loading, sharing, importing, refreshing, pushing updates, viewing assets, and managing linked assets.

The most important technical distinction is:

Snapshot ≠ Live Clone

and:

Snapshot ≠ Complete Backup

Changes in the source account do not automatically synchronize to an existing snapshot.

Instead:

Source Changes

↓

Refresh

↓

Snapshot Changes

Then, where appropriate:

Push Update

↓

Selected Linked Sub-Accounts.

That controlled separation is valuable.

It lets an agency maintain a master architecture without automatically overwriting every client environment whenever development occurs.

Snapshots also support a larger business strategy.

An agency can progress from:

Custom Implementation

↓

Repeatable Implementation

↓

Standardized Master

↓

Snapshot

↓

Productized Service

↓

SaaS Provisioning

or:

Marketplace Product

HighLevel currently supports both Marketplace snapshot monetization and snapshot inclusion within eligible SaaS plans.

But scale creates responsibility.

The more client accounts depend on one master system, the more important:

Testing

Versioning

Documentation

Permissions

Deployment Control

Dependency Management

and:

QA

become.

A weak snapshot can replicate mistakes faster.

A strong snapshot can replicate proven architecture faster.

That is the real value of the feature:

Standardize what works, customize what must differ, and control how changes reach production.

Start Your GoHighLevel 30-Day Free Trial →