A form submission that produces the first text message has not tested the workflow. It has tested one moment of one path.

The risk sits in the transitions: a second submission from the same person, a reply that arrives during a wait, a booking that should stop pre-booking follow-up, a contact who returns months later. Pre-launch testing is the work of proving that each agreed path produces the agreed records, states, messages, and stops, and then keeping evidence that it did.

This guide covers the method: what to define before testing, how to set up test contacts, how to write a scenario, where to look in GoHighLevel for the actual result, what to do when a scenario fails, and when a build is ready to sign off. A condensed checklist sits at the end.

Define “done” before writing a single test

A test can only pass or fail against an expectation. Before any scenario is written, agree on:

  • The scope boundary. Which entry points, pipelines, workflows, notifications, and handoffs are in this launch, and which are explicitly out.
  • The lifecycle states. What each pipeline stage, tag, or field means, and which event makes it true.
  • The stopping rules. Which events should end, pause, or redirect automation: a reply, a booking, a disqualification, an opt-out, a manual takeover, a completed handoff.
  • The owner of each exception. Who sees a lead that cannot follow the normal route, and how.

If these definitions are still moving, testing will mostly measure the disagreement. Mapping the lead-to-booking workflow is the step that produces them. Each mapped decision should become a requirement, and each requirement should become at least one scenario.

Prepare the test environment

Test in a published workflow, deliberately

HighLevel states that workflows run when they are published and their trigger conditions are met; a draft does not act on live contacts. That makes publication part of the test, not a step after it. If a workflow has to be published while live traffic can still reach it, one option is to restrict entry during QA, for example with a trigger filter that only admits marked test contacts. If you do, treat removing that restriction as its own launch step with its own retest. A QA-only filter left in place is a launch defect.

Use fresh, controlled test contacts

  • One new contact per scenario. HighLevel recommends testing with a contact that has not entered the workflow before, so prior enrollment and re-entry restrictions do not affect the result. Reusing one contact across scenarios makes later results depend on earlier ones.
  • Name contacts by scenario. A name such as “QA-07 Reply during wait” makes logs readable and makes cleanup reliable.
  • Use addresses and numbers the team controls. Test runs send real communication. HighLevel’s webhook documentation states that running a test executes the entire workflow for the contact, including firing outbound webhooks.
  • Never test on real customer records.

Prepare the log before the first run

Create the scenario sheet first (the next section describes its columns) and decide where evidence will be stored. Screenshots taken later from memory are not evidence.

Write each scenario with its expected result first

Every scenario needs a starting condition, an action, and an expected result written in observable terms. “Works” is not an expected result. “Opportunity created in the intake pipeline at New Inquiry, owner assigned, acknowledgement sent once, no internal notification duplicated” is.

Column What it records
ID A stable reference, such as QA-07
Scenario One sentence describing the path being proved
Starting state Contact and opportunity state before the action: new or existing, tags, stage
Action Exactly what the tester does, including timing where it matters
Expected record and state Contact fields, tags, opportunity, pipeline, stage, owner
Expected communication Which messages go out, on which channel, and how many times
Expected stop or exit Which event ends or redirects the path, and the expected Enrollment History status
Evidence Where the actual result was confirmed
Result Pass, fail, or accepted deviation, with the date

Write the expected result before running the scenario. If it is written afterward, the actual result tends to become the expectation.

Cover the paths most likely to break

The categories below cover the transitions where a lead workflow can diverge from its design. Use only the ones in scope for the build.

Category What to prove Example scenario
Entry and enrollment The right event enrolls the right contact once New inquiry from the main form enters the intake workflow
Record creation and duplicates Repeat submissions update the intended record instead of creating competing ones The same person submits twice within an hour
Source and attribution In-scope source and UTM context survive the capture path A submission arrives from a tagged campaign URL
Pipeline state Opportunities are created or updated in the right pipeline, stage, and owner A booking moves the opportunity to the booked stage
Ownership and internal actions Tasks and notifications reach the right person, once An urgent request creates a review task for the assigned owner
Timing Waits, the workflow time window, and timezone behave as designed A message becomes due outside the allowed hours
Replies A reply stops, pauses, or branches the path as specified The contact replies during the second wait
Booking changes Booked, rescheduled, cancelled, and no-show events lead to their defined states The contact cancels after booking
Suppression and exits Opt-outs, disqualification, and completed handoff stop automation An out-of-area request leaves the nurture path
Re-entry and reset A genuinely new request is visible without reviving an old path A past contact submits a new request
Workflow collisions Two workflows responding to the same event do not compete A tag that triggers two workflows is applied
Error and exception paths Missing data or blocked channels produce a visible review state A submission arrives without a phone number
Handoff The final state reaches the person or system responsible for fulfillment A won opportunity creates the documented handoff

A useful rule when a list grows: a scenario is worth keeping when its input or its expected result differs meaningfully from every other scenario. Two scenarios that exercise the same trigger, filter, and branch with different names are one test.

Run the scenario and capture the actual result

Check the actual result where GoHighLevel records it, not where the team expects to see it:

  • Contact record: fields, tags, DND settings, and the activity history.
  • Opportunity: pipeline, stage, owner, and status.
  • Conversations: which messages were sent and when. HighLevel’s message details link to the workflow execution that sent the message.
  • Trigger statistics: whether the trigger attempted, matched, or did not match the test contact, with a stated reason for any unmatch.
  • Enrollment History: whether the contact completed, is still in progress, or was removed, and by which workflow. Highlight Contact Path shows the branch the contact actually followed.
  • Execution Logs: each action’s status, errored actions, and full details through View Details, with the execution time and timezone.
  • Receiving systems: for webhooks, the receiving endpoint’s own log. HighLevel’s documentation notes that the execution log confirms the webhook was sent but does not show the payload.

Record which of these confirmed the result in the Evidence column. A scenario passes only when every expected element matches, including the things that should not have happened, such as a second message or a notification to the wrong person.

Handle failures without losing the record

When a scenario fails:

  1. Log the defect before fixing it. Record the scenario ID, expected result, actual result, evidence, and suspected cause.
  2. Diagnose before changing configuration. Trigger statistics, Enrollment History, and Execution Logs usually show whether the cause is the trigger, a setting, a condition, timing, or another workflow. The diagnostic order is covered in GoHighLevel workflow not triggering?
  3. Fix one cause at a time. Several simultaneous changes make the next result impossible to attribute.
  4. Retest with a new contact. The failed contact’s history now reflects the defect.
  5. Retest the neighbors. Any scenario that shares the changed trigger, filter, condition, tag, or stage needs to run again. A fix to the reply path can break the booking path.
  6. Do not edit the expectation to match the result. If the requirement itself was wrong, record that decision and who approved it, then update the scenario.

Publish-blocking configuration errors are a separate, earlier gate. HighLevel’s builder flags issues such as missing mandatory fields or invalid If/Else and Wait settings and will not publish until they are resolved, but it also cautions that pre-publish validation may not catch every problem. A workflow that publishes cleanly still needs its scenarios run.

Sign off only when the evidence supports it

A lead workflow is ready to launch when:

  • every in-scope scenario has a recorded actual result and evidence;
  • every scenario passed, or each deviation was explicitly accepted by the system owner with a reason;
  • no execution in the logs is unexplained;
  • QA-only restrictions are removed, and the live entry points have been tested after removal;
  • test contacts are archived or removed according to the team’s data rules;
  • the handoff notes describe the states, stopping rules, owners, and where to look when something misbehaves;
  • someone is named to review the first live leads.

Record the acceptance point: the date and the configuration that was tested. A QA result is true for that configuration at that time. A later edit to a trigger, filter, wait, or tag is a new configuration and needs its affected scenarios retested.

What this looks like in a verified build

In one verified Edex implementation, a three-page funnel, an eight-stage pipeline, and seven canonical workflows were built as one lead lifecycle, including attribution and UTM handling, duplicate-prevention rules, and suppression and exit logic. The build was tested against 23 documented QA scenarios covering the agreed system paths, and all 23 passed at the recorded acceptance point before deployment and handoff.

Two limits on that evidence matter. The project record confirms the scenario count and the pass result but not publishable scenario titles, so the categories in this guide are a method, not that project’s test list. And a pass at acceptance does not establish permanent error-free operation; it establishes that the agreed paths behaved as specified when they were tested.

The useful lesson is not the number 23. It is that the scope, the build, and the acceptance record traced to the same agreed behavior.

What Edex would not do

  • Sign off because the builder’s test run completed without errors.
  • Reuse one test contact for every scenario and treat the final state as proof.
  • Test only the path where a new lead submits once and books.
  • Launch with a QA-only filter still restricting entry.
  • Change a scenario’s expected result after the fact to make it pass.

Pre-launch checklist

Before testing

  • Scope boundary agreed: entry points, pipelines, workflows, handoffs in and out
  • States, stopping rules, and exception owners defined
  • Scenario sheet created with expected results written for every scenario
  • Test contacts prepared: one per scenario, named by scenario ID, using channels the team controls
  • Any QA-only entry restriction documented as a launch step

During testing

  • Each scenario run with a fresh contact
  • Actual result checked in the contact, opportunity, conversations, trigger statistics, Enrollment History, and Execution Logs
  • Things that should not happen confirmed absent: duplicate messages, wrong notifications, competing workflows
  • Webhook results confirmed in the receiving system
  • Evidence location recorded for every result

When a scenario fails

  • Defect logged before any change
  • Cause diagnosed from the logs
  • One cause fixed at a time
  • Failed scenario retested with a new contact
  • Neighboring scenarios that share the changed signal retested

Sign-off

  • All scenarios passed or deviations accepted in writing
  • No unexplained executions
  • QA-only restrictions removed and live entry points retested
  • Test contacts handled according to data rules
  • Handoff notes complete
  • Acceptance date and tested configuration recorded
  • First live leads reviewed by a named person

Build it so it can be tested

Testing is easier when the workflow was designed around clear states and stopping rules from the start. If the lifecycle, pipeline, and workflows need to be built and accepted together, GHL CRM & Automation covers that work; if the entry point is a new or rebuilt website, GoHighLevel Website Design includes connecting it to the same tested path.