How to Test a Workflow Before Publishing It to Clients in GoHighLevel

Testing a workflow before it goes live is one of the most important steps in any automation setup. Skipping this phase often leads to duplicate messages, broken triggers, or missed actions that affect real contacts. This guide walks you through the available methods for safely testing a GoHighLevel workflow, explains what each method does and does not cover, and highlights the most common mistakes to avoid.

Why Testing Matters Before You Publish

GoHighLevel workflows can include conditional branches, wait steps, external webhooks, SMS/email actions, and CRM field updates — all of which interact with live data once activated. A workflow that looks correct in the builder can still behave unexpectedly when real trigger conditions are met.

Testing allows you to:

• Confirm that the correct branch fires under the correct condition
• Verify that contact data populates dynamic fields (custom values, contact tokens) as expected
• Check that third-party integrations (webhooks, Zapier, etc.) receive the right payload
• Ensure wait steps and time delays are configured correctly before a contact sits in limbo

Keep in mind that no testing method fully replicates every production scenario, especially around time-based delays. Plan your tests accordingly.

Step 1 — Set the Workflow to Draft or Inactive Status

Before doing anything else, make sure your workflow is not set to Published and Active while you are still building or testing it.

1. Open Automation from the left sidebar.
2. Select Workflows.
3. Open your workflow or create a new one.
4. In the top-right area of the workflow builder, check the toggle. If it shows Published, click it to switch to Draft (or Inactive, depending on your interface version).
5. Save your progress before proceeding.

A workflow in Draft status will not fire for real contacts entering through live triggers. This is your safety net during the testing phase.

Step 2 — Use the Built-In "Test Workflow" Feature

GoHighLevel provides a native way to run a contact through a workflow manually, without waiting for a live trigger event.

1. Inside the workflow builder, look for the Test Workflow button (typically near the top toolbar).
2. Click it. A panel or modal will appear asking you to select a contact.
3. Search for and select a test contact — ideally a contact you created specifically for QA purposes using your own email and phone number.
4. Confirm the selection and click Run Test (the exact label may vary by platform version).
5. The workflow will execute from the first step using that contact's data.

Important caveats:

• Real actions may still fire during a test run, including sending actual SMS messages or emails to the selected contact. Use a dedicated test contact with your own details to avoid messaging real clients.
• Wait steps and time delays are generally not skipped during a standard test run. If your workflow has a 24-hour wait, the test contact will actually pause at that step.
• Some action types, such as those tied to payment or appointment steps, may behave differently in test mode depending on your plan and integration setup.

Creating a Dedicated Test Contact

If you do not already have one, create a contact using your own name, email address, and a phone number you control. Tag it clearly (e.g., "QA Test — Do Not Delete") so it is easy to find and not accidentally removed during contact list cleanups.

Step 3 — Review Action Results and Logs

After triggering a test run, you need to verify what actually happened.

1. Go to Automation → Workflows and open your workflow.
2. Click on the History or Execution Log tab (availability may vary by plan).
3. Locate the test contact's execution record and expand it.
4. Review each step: look for green checkmarks (success), yellow warnings, or red errors.
5. For email and SMS actions, check your own inbox and phone to confirm delivery and that dynamic fields (like {{contact.first_name}}) resolved correctly.
6. For webhook actions, check the receiving endpoint (your server logs, RequestBin, or Webhook.site) to confirm the payload structure.

If the execution log is not available on your current plan, you can partially verify results by checking the contact's activity feed in the Contacts section.

Step 4 — Test Individual Trigger Conditions

The test button runs the workflow body, but it does not validate whether your trigger conditions will actually fire in real scenarios. Test those separately.

• Form submission triggers: Submit your actual test form using the test contact's information and confirm the workflow starts.
• Tag-based triggers: Manually add the relevant tag to your test contact from the contact record and observe whether the workflow initiates.
• Pipeline stage triggers: Move your test contact into the target pipeline stage and check for workflow activation.
• Appointment triggers: Book a test appointment under the test contact and verify the trigger fires.

Document what you tested and what the expected versus actual result was. This record is useful if something breaks after publishing.

Common Errors and Troubleshooting

The workflow does not start during a trigger test. Check that the workflow status is set to Active (not Draft) when testing live triggers. Workflows in Draft mode will not respond to real trigger events. Switch to Active only during trigger validation, then revert if needed, or publish when you are confident.

Dynamic fields show placeholder text instead of real values. This usually means the contact record is missing the data the token references. Open the test contact's profile and confirm that fields like first name, email, or custom fields are populated before running the test.

The test contact received a real SMS or email. This is expected behavior. GoHighLevel does not sandbox all action types in test mode. Always use a contact with your own details, and make sure your test phone number is connected to an active number in your sub-account to receive and verify SMS delivery.

Wait steps are blocking the test and you cannot see downstream actions. There is no native "skip delays" option available in all plans. One workaround is to temporarily set wait steps to a very short duration (e.g., 1 minute) during testing, verify the full flow, and then restore the original timing before publishing.

The execution log shows an error on a webhook step. Copy the error message and check it against your endpoint's expected payload format. Common causes include missing required fields, incorrect content-type headers, or authentication failures on the receiving server.

Workflow fires multiple times for the same contact. Check the Allow Re-entry setting inside the workflow options. If re-entry is enabled without a condition, the same contact can enter the workflow repeatedly every time the trigger fires.

Before You Hit Publish

Once testing is complete, do a final review checklist:

• All action steps have green status in the execution log
• Dynamic fields resolved correctly in emails and SMS messages
• Trigger conditions were validated with a real event (not just the test button)
• Wait step durations are set to their intended production values
• The Allow Re-entry setting matches your intended behavior
• Any connected integrations (webhooks, Zapier, third-party CRMs) confirmed receipt of correct data

Only after confirming each of these points should you flip the workflow to Published and Active. If your use case involves high-volume contacts or financial transactions, consider a limited rollout — for example, applying the workflow only to a specific segment or tag before expanding it to your full contact list.