GoHighLevel Snapshot QA Service: How We Test a Clean Subaccount

A GoHighLevel snapshot test must prove the business journey, not just show a tidy workflow canvas. We approve a release when it loads into a clean sub-account and the agreed paths produce the expected records, messages and human handoffs.

1. Freeze the release candidate

Before testing, we name the version, list the included assets and stop casual edits. Otherwise a fix made during QA can create a new untested build while the team assumes the old test still applies.

2. Review dependencies

• Triggers and required tags
• Fields used by forms, filters and branches
• Custom values used in copy or links
• Pipeline and opportunity stages
• Calendar, owner and meeting location
• Templates, users, phone, email and integrations

3. Test every branch with a separate contact

One test contact cannot prove every path. For the coaching build, we use separate records for a qualified lead who books, a qualified lead who does not book, a no-show who rebooks and a no-show who does not.

Scenario	Expected result
Application submitted	Pending-review status and reviewer notification
Qualified, then books	Booking invitation, appointment found, no unnecessary follow-up
Qualified, no booking	One follow-up and completion status
No-show, then rebooks	Recovery starts and closing message is skipped
No-show, no rebooking	One closing message and completion status

4. Test content and experience

We read messages on a phone, click every link, preview forms at small widths and book the calendar as a visitor. We verify the sender identity, reply behavior, timezone, confirmation and what the team sees in the contact record.

5. Load into a clean account

The source account can hide dependencies because old fields, tags or values already exist. A clean-account load exposes what the snapshot actually carries and what the installation must provide.

6. Make a release decision

• Ready: agreed journeys pass and only documented client connections remain.
• Ready after fixes: the failures are known, bounded and assigned.
• Do not deploy: a core journey, consent, attribution or handoff remains unreliable.

Evidence we keep from the test

• A release manifest showing the snapshot version and included assets.
• One test record per important branch, with expected and actual results.
• Screenshots of the workflow state, contact timeline, opportunity and appointment.
• A list of fixes made after the first run and the exact cases retested.
• Named owners for every client connection or limitation that remains after import.

The QA report should include the version, test cases, evidence, failures, fixes, remaining client connections and the release decision. That is more valuable than a screenshot of a large workflow.

Our six-failure snapshot audit shows what this process caught in the executive-coaching build.