VATable Workflows Guide

GoHighLevel Automation Reference
Last updated: 18 March 2026

This guide documents every active workflow in VATable's GoHighLevel account. It explains what each workflow does, when it fires, what the team should expect, and how to verify, pause, or manually trigger workflows.

Contents

  1. Where to Find Workflows in GHL
  2. Workflow Overview & Status
  3. How Workflows Fire (Trigger Types)
  4. WF1-WF4: BDM Loop Workflows
  5. WF7: Service Completed → Ruby Task
  6. WF8: 64-8 Signed → Auto-Note
  7. WF9: Expiry Date → Stage Change
  8. WF10: End of Engagement Review → Ruby Invoice Task
  9. WF11: Case Management Stage Entry → Owner Task
  10. WF12: Expiry Warning → Ruby Task
  11. WF13: NMF Kill Switch
  12. Legacy Workflows (Pre-existing)
  13. How to Check Workflow Execution Logs
  14. How to Pause/Disable a Workflow
  15. How to Add a Contact to a Workflow Manually
  16. Quick Reference Table

2. Workflow Overview & Status

VATable currently has 51+ workflows in the account. Of these, 23+ are published and actively running. The key workflows documented in this guide are WF1–WF4 (BDM loop) and WF7–WF13 (case management and automation), plus two legacy workflows.

Ref Workflow Name Status Trigger Type
WF1 1. BD Follow Up Live Pipeline Stage Changed
WF2 1. BD - NMF (Not Moving Forward) Live Pipeline Stage Changed
WF3 2. BD - Send Proposal Live Pipeline Stage Changed
WF4 1. BD - Unable to Contact Live Pipeline Stage Changed
WF7 Service Completed → Ruby Task Live Pipeline Stage Changed
WF8 64-8 Signed → Auto-Note Live Document Signed
WF9 Engagement Expiry → End of Engagement Review Live Custom Date Reminder
WF10 End of Engagement Review → Ruby Invoice Task Live Pipeline Stage Changed
WF11 Case Management Stage Entry → Owner Task Live Pipeline Stage Changed
WF12 Engagement Expiry Warning → Ruby Task Fix Needed Custom Date Reminder
WF13 NMF Kill Switch → Remove from All Workflows Live Pipeline Stage Changed
— 3. Documents Signed → Case Management Investigating Document Signed
— 2. BD - Send Proposal - Opportunity Fix Needed Pipeline Stage Changed

3. How Workflows Fire (Trigger Types)

VATable's workflows use three main trigger types. Understanding these helps you predict when automations will run.

Pipeline Stage Changed Most Common

Fires when an opportunity is moved to a specific stage in a pipeline. This is the most common trigger.

When it fires The moment someone drags an opportunity card to a new stage, or the stage is changed via API/workflow Used by WF1-WF4, WF7, WF10, WF11, WF13 Key setting Must specify the pipeline AND the stage(s) that trigger it

Document Signed

Fires when a client signs a document (e.g., 64-8 authorisation, engagement letter) via GHL's Documents & Contracts feature.

When it fires The moment a client completes signing the document digitally Used by WF8, Legacy "Documents Signed" workflow Key setting Can filter by specific document template ID

Custom Date Reminder Limitation

Fires based on a date stored in a custom contact field. Important limitation: GHL's Custom Date Reminder has NO offset option — it fires on the exact date stored in the field, not "X days before" or "X days after".

When it fires On the exact date stored in the custom field (at a time you configure) Used by WF9, WF12 Workaround Create a separate date field pre-calculated with the offset (e.g., "Engagement Warning Date" = expiry date minus 7 days)
GHL Limitation

Unlike calendar apps that let you set "remind me 7 days before", GHL Custom Date Reminder triggers on the exact date only. To fire a workflow in advance, you must store a pre-calculated date in a separate custom field.

4. WF1–WF4: BDM Loop Workflows

These four workflows manage the Business Development Manager (BDM) process — the journey from initial enquiry through follow-up to proposal or exit. They were split from a single large workflow into four separate ones for reliability.

WF1: BD Follow Up Live

Trigger Pipeline Stage Changed → MASTER: VATable Sales Pipeline → Follow Up What it does Manages the follow-up sequence for new enquiries. Sets tasks and reminders for the assigned BDM to contact the prospect. Who it affects Ian Sutton (primary BDM), or whoever is assigned as contact owner

WF2: BD - NMF (Not Moving Forward) Live

Trigger Pipeline Stage Changed → MASTER: VATable Sales Pipeline → Not Moving Forward What it does Handles contacts that are not proceeding. Part of the original BDM loop split. Note WF13 (NMF Kill Switch) is a separate, newer workflow that also triggers on NMF but performs a different function (removing from all workflows).

WF3: BD - Send Proposal Live

Trigger Pipeline Stage Changed → MASTER: VATable Sales Pipeline → Proposal Sent What it does Initiates the proposal/engagement letter sending process when a BDM moves an opportunity to "Proposal Sent". Who it affects The contact/prospect and the BDM

WF4: BD - Unable to Contact Live

Trigger Pipeline Stage Changed → MASTER: VATable Sales Pipeline → Unable to Contact (or similar stage) What it does Handles the scenario where the BDM cannot reach the prospect. May include retry sequences. Who it affects Ian Sutton or assigned BDM

5. WF7: Service Completed → Ruby Task

Service Completed → Create Task for Ruby Campbell Live WF7

Opp moves to "Service Completed" → Create Task for Ruby → Ruby reviews & requests testimonial
Trigger Pipeline Stage Changed → MASTER: VATable Sales Pipeline → Service Completed Action Creates a task assigned to Ruby Campbell with a 1-day due date Task content Review the completed case, check all work is finalised, and reach out to the client for a testimonial/review Published 17 March 2026

What Ruby Should Do

  1. Check the task appears in your GHL Tasks list (Contacts → Tasks)
  2. Open the contact record and review the case details
  3. Confirm all deliverables have been completed
  4. Send the client a thank-you message and request a testimonial
  5. Mark the task as complete once done

How to Verify It Fired

Go to the contact record → scroll down to "Active Automations" in the right sidebar. The workflow will appear there if currently running. Alternatively, check the Tasks list for a new task assigned to Ruby.

6. WF8: 64-8 Signed → Auto-Note

64-8 Signed → Auto-Note on Contact Live WF8

Client signs 64-8 document → Add Note to Contact → Permanent record of HMRC authorisation
Trigger Document Signed (64-8 authorisation form) Action Adds an internal note to the contact record Note text HMRC 64-8 authorisation received and completed for {{opportunity.per_month_for}} months Published 17 March 2026 (merge field fixed 18 March 2026)

What This Logs

When a client digitally signs their 64-8 HMRC authorisation form, this workflow automatically adds a timestamped note to the contact's record. The note includes the number of months the authorisation covers, pulled from the opportunity's per_month_for field.

How to Verify It Fired

  1. Open the contact record in GHL
  2. Scroll to the Notes section (or click the Notes tab in the contact detail)
  3. Look for a note that reads: "HMRC 64-8 authorisation received and completed for X months"
  4. The note will have a timestamp showing when it was created automatically
Merge Field

The {{opportunity.per_month_for}} merge field pulls data from the opportunity's custom fields. If this field is empty on the opportunity, the note will show a blank where the month count should be. Make sure this field is populated when creating the opportunity.

7. WF9: Engagement Expiry Date → Stage Change

Engagement Expiry → Move to End of Engagement Review Live WF9

Engagement Expiry Date reached → Move opp to End of Engagement Review → Create task for case owner → Owner discusses renewal
Trigger Custom Date Reminder on Engagement Expiry Date field (ID: lUccKbEHj5ZnmW1wXtFj) Actions 1. Moves opportunity to Case Management Pipeline → End of Engagement Review stage
2. Creates a task for the contact owner to review the engagement and discuss new terms Published 17 March 2026

How This Works

When the date stored in the contact's Engagement Expiry Date custom field arrives, this workflow fires automatically. It performs two actions:

  1. Moves the opportunity from its current stage in Case Management to the "End of Engagement Review" stage
  2. Creates a task for the case owner (whoever is assigned to the contact) to review the engagement and reach out to the client about renewal or new terms
Correct Behaviour

WF9 fires on the exact expiry date. This is the intended behaviour — the engagement has actually expired, so the review process begins. For an advance warning before expiry, see WF12.

What the Case Owner Should Do

  1. Open the task when it appears
  2. Review the client's engagement terms and history
  3. Contact the client to discuss whether they want to renew, amend, or end the engagement
  4. If renewing, update the Engagement Expiry Date field with the new date
  5. Mark the task as complete

8. WF10: End of Engagement Review → Ruby Invoice Task

End of Engagement Review → Invoice Generation Task for Ruby Live WF10

Opp enters "End of Engagement Review" → Create Task for Ruby → Ruby generates final invoice
Trigger Pipeline Stage Changed → Case Management Pipeline → End of Engagement Review Action Creates a task assigned to Ruby Campbell with subject "Generate Invoice" and a 1-day due date Published 18 March 2026

What Ruby Should Do

  1. When the "Generate Invoice" task appears, open the contact/opportunity record
  2. Review the engagement terms and outstanding amounts
  3. Generate the final invoice in GHL Payments → Invoices → + New
  4. Send the invoice to the client
  5. Mark the task as complete
Chain with WF9

WF10 typically fires after WF9. When the engagement expiry date arrives, WF9 moves the opportunity to "End of Engagement Review". This stage change then triggers WF10, which creates the invoice task for Ruby. The two workflows work as a chain.

9. WF11: Case Management Stage Entry → Owner Task

Case Management Stage Entry → Owner Review Task Live WF11

Opp enters ANY Case Management stage → Create Task for Contact Owner → Owner reviews case within 2 days
Trigger Pipeline Stage Changed → Case Management Pipeline → ANY stage (Time to Pay, Direct Tax, VAT, Miscellaneous, End of Engagement Review) Action Creates a task assigned to the Contact Owner with a 2-day due date Task purpose Review the case status and reach out to the client Published 18 March 2026

When This Fires

This workflow fires every time an opportunity moves into any stage of the Case Management Pipeline. The stages are:

What the Case Owner Should Do

  1. Within 2 days of the task appearing, open the contact record
  2. Review the case details, current status, and any outstanding actions
  3. Reach out to the client to provide an update or request information
  4. Log any notes from the review on the contact record
  5. Mark the task as complete
Note

Since this fires on ANY stage change, it will also fire when WF9 moves an opportunity to "End of Engagement Review". In that case, the case owner will get both the WF9 task (engagement review) and the WF11 task (general case review). Both should be actioned.

10. WF12: Engagement Expiry Warning → Ruby Task

Engagement Expiry Warning → Ruby Task Fix Needed WF12

Warning date reached → Create Task for Ruby → Ruby flags upcoming expiry
Trigger Custom Date Reminder on Engagement Expiry Date field (ID: lUccKbEHj5ZnmW1wXtFj) Action Creates a task assigned to Ruby Campbell with a 1-day due date to warn of upcoming engagement expiry Published 18 March 2026 Status Currently fires on the exact expiry date (same day as WF9). Needs updating to fire 7 days earlier.
ACTION REQUIRED: Charles Dobson

What needs to happen: WF12's trigger needs to be changed from the "Engagement Expiry Date" field to the "Engagement Warning Date" field.

Why: GHL's Custom Date Reminder has no offset option. Currently, WF12 fires on the same day as WF9 (the expiry date itself), which defeats the purpose of a warning. The workaround is to use a separate date field calculated 7 days before expiry.

New field created: "Engagement Warning Date" (field ID: 8JHpXhSltR6mFqosqv08)

Steps:

  1. Open WF12 in Automation → Workflows
  2. Click on the trigger step (Custom Date Reminder)
  3. Change the date field from "Engagement Expiry Date" to "Engagement Warning Date"
  4. Save and publish
  5. When creating/updating engagements, ensure the "Engagement Warning Date" field is set to 7 days before the actual expiry date

How WF12 Should Work (After Fix)

  1. When a new engagement starts, someone sets the Engagement Expiry Date and also sets the Engagement Warning Date to 7 days earlier
  2. 7 days before expiry, WF12 fires and creates a task for Ruby
  3. Ruby reviews the upcoming expiry and alerts the relevant team member
  4. On the actual expiry date, WF9 fires and moves the opportunity to End of Engagement Review

11. WF13: NMF Kill Switch

NMF Kill Switch → Remove from All Workflows Live WF13

Opp moves to "Not Moving Forward" → Remove from ALL Workflows → Add tag "nmf-cleared" → All automations stopped
Trigger Pipeline Stage Changed → "Not Moving Forward" stage in:
1. MASTER: VATable Sales Pipeline
2. SALES: Ian Sutton Actions 1. Remove from ALL Workflows (stops every active automation for this contact)
2. Add Tag: nmf-cleared (confirms the kill switch ran) Workflow ID 7cbc74c0-d47c-481f-8317-156158157902 Published 18 March 2026

Why This Is Important

When a prospect or client is moved to "Not Moving Forward", they should no longer receive any automated emails, SMS messages, or follow-up sequences. Without this workflow, contacts could continue receiving BDM follow-up emails, proposal reminders, or other automated communications even after the decision was made to stop pursuing them.

How to Verify It Worked

  1. Open the contact record in GHL
  2. Check the Tags section — you should see the nmf-cleared tag
  3. Check the Active Automations section in the right sidebar — it should be empty
  4. If both conditions are true, the kill switch ran successfully
Important: This is Irreversible (for workflows)

Once this workflow runs, the contact is removed from all active workflows. If the contact later needs to be re-engaged, you would need to manually add them back to the relevant workflows. The nmf-cleared tag serves as a permanent record that the kill switch was activated.

Covers Both Pipelines

WF13 monitors two pipelines for the "Not Moving Forward" stage:

No matter which pipeline the opportunity is in, moving it to NMF will trigger the kill switch.

12. Legacy Workflows (Pre-existing)

These workflows existed before the 17-18 March 2026 build session. They are still active but have known issues under investigation.

3. Documents Signed and Moved to Case Management Investigating

Trigger Document Signed (engagement letter) Actions Finds the opportunity, moves it from Proposal Sent to Engagement Signed, then transfers to Case Management Enrollments 27 contacts have been through this workflow Known issue The "Find Opportunity" step may fail if the opportunity is not in the "Proposal Sent" stage at the time of signing. Also, the documentCreatedByTemplateId condition may be checking an outdated template ID.
ACTION REQUIRED: Investigation

To diagnose: Open this workflow → Execution Logs → find a recent signing event → check which branch the contact went down. If the "Find Opportunity" step shows "No opportunity found", the stage filter is the issue.

2. Business Development - Send Proposal - Opportunity Fix Needed

Trigger Pipeline Stage Changed → Proposal Sent Actions Sends the engagement letter to the prospect Enrollments 116 contacts (very active workflow) Workflow ID abfa6fa0-1ad9-4bf4-af0b-db826c509882 Known issue May send the engagement letter twice to some contacts. Needs a tag guard.
ACTION REQUIRED: Tag Guard Fix

Fix needed: Add an If/Else check at the start of this workflow:

  1. If contact has tag engagement-letter-sent → Remove from Workflow (stop, already sent)
  2. If contact does NOT have the tag → Continue with sending the letter
  3. After the letter-sending step, add an action: Add Tag engagement-letter-sent

Direct link: Open workflow in GHL

13. How to Check Workflow Execution Logs

If you need to verify whether a workflow ran for a specific contact, follow these steps.

Method 1: From the Workflow (Best for Overview)

  1. Go to Automation in the left sidebar
  2. Find the workflow you want to check and click on it to open the builder
  3. Look for the Execution Logs tab (sometimes labelled "History" or accessible via the three-dot menu)
  4. You can filter by date range and see which contacts entered the workflow, which steps they completed, and any errors
  5. Click on a specific contact's entry to see the step-by-step execution path

Method 2: From the Contact Record (Best for One Person)

  1. Go to Contacts and find the person
  2. Open their contact detail page
  3. In the right sidebar, scroll down to Active Automations
  4. This shows which workflows the contact is currently enrolled in
  5. For historical workflow activity, check the Activity or Timeline tab on the contact record

What to Look For

14. How to Pause/Disable a Workflow (Emergency Stop)

If a workflow is misfiring or causing issues, you can disable it immediately.

To Disable a Workflow

  1. Go to Automation → Workflows
  2. Find the workflow in the list
  3. Look for the toggle switch on the right side of the workflow row (Published/Draft)
  4. Click the toggle to switch it from Published to Draft
  5. Confirm the action when prompted
What Happens When You Disable

New contacts will no longer enter the workflow. However, contacts already inside the workflow may continue to receive actions until they reach the end of their current path. To stop all in-progress contacts immediately, you may need to use the "Remove All" option if available.

To Re-enable a Workflow

  1. Open the workflow
  2. Toggle it back to Published
  3. It will immediately start accepting new triggers again
Before You Disable

Always check the workflow's execution logs first. The issue might be with data (missing fields, wrong stage) rather than the workflow logic itself. Disabling a workflow stops ALL contacts from entering it, which could cause missed follow-ups.

15. How to Add a Contact to a Workflow Manually

If a workflow should have fired but didn't (e.g., due to a timing issue or a recently fixed bug), you can manually enrol a contact.

Method 1: From the Contact Record

  1. Open the contact's record in Contacts
  2. In the right sidebar, scroll to Active Automations and click the + button (or "Add to Workflow")
  3. A list of published workflows will appear
  4. Select the workflow you want to add them to
  5. The contact will enter the workflow from the beginning (the trigger step is skipped)

Method 2: From the Workflow Builder

  1. Go to Automation → Workflows
  2. Open the workflow you want to add the contact to
  3. Look for the "Add Contact" or "Manual Enrollment" option (usually in the top-right area or under the three-dot menu)
  4. Search for and select the contact
  5. The contact will be enrolled and start running through the workflow steps

Method 3: Re-trigger by Stage Change

For workflows triggered by Pipeline Stage Changed, you can re-trigger them by:

  1. Moving the opportunity out of the trigger stage (e.g., back to the previous stage)
  2. Then moving it back to the trigger stage
  3. This simulates the original stage change and should fire the workflow
Caution with Re-triggering

Moving an opportunity back and forth through stages will trigger ALL workflows that monitor those stages, not just the one you want. Check which other workflows are listening to the same stages before using this method. You may accidentally fire WF13 (NMF Kill Switch) if you move through "Not Moving Forward".

16. Quick Reference Table

Ref Workflow Trigger Key Action Who Status
WF1 BD Follow Up Stage → Follow Up BDM follow-up sequence Ian S. Live
WF2 BD - NMF Stage → NMF NMF handling (BDM loop) Ian S. Live
WF3 BD - Send Proposal Stage → Proposal Sent Send engagement letter Prospect Live
WF4 BD - Unable to Contact Stage → Unable to Contact Retry sequence Ian S. Live
WF7 Service Completed Stage → Service Completed Task: review + testimonial Ruby C. Live
WF8 64-8 Signed Document Signed Auto-note: HMRC auth Auto Live
WF9 Engagement Expiry Date Reminder Move to Review + owner task Case Owner Live
WF10 End of Engagement Review Stage → EoE Review Task: Generate Invoice Ruby C. Live
WF11 Case Mgmt Stage Entry Stage → Any CM stage Task: 2-day case review Case Owner Live
WF12 Expiry Warning Date Reminder Task: warn of expiry Ruby C. Fix Needed
WF13 NMF Kill Switch Stage → NMF (both pipelines) Remove from ALL workflows + tag Auto Live

Key Custom Fields

Field Name Field ID Used By Notes
Engagement Expiry Date lUccKbEHj5ZnmW1wXtFj WF9, WF12 (currently) The actual engagement end date
Engagement Warning Date 8JHpXhSltR6mFqosqv08 WF12 (after fix) Should be set to Expiry Date minus 7 days

Key Tags

Tag Set By Meaning
nmf-cleared WF13 Contact was removed from all workflows via NMF Kill Switch
engagement-letter-sent Manual / fix pending Proposed tag guard to prevent duplicate engagement letters (fix pending on legacy proposal workflow)
enquiry submitted Form submission Contact submitted an enquiry (most common tag — applied to majority of contacts)

Outstanding Action Items

Priority Item Owner Details
High WF12: Update trigger field Charles D. Change trigger from "Engagement Expiry Date" to "Engagement Warning Date" field. See WF12 section.
High Legacy Proposal: Add tag guard Charles D. Add If/Else with engagement-letter-sent tag check to prevent duplicate letters. See Legacy section.
Med Legacy Doc Signed: Investigate trigger Charles D. Check execution logs to determine why "Find Opportunity" step fails. See Legacy section.

VATable Ltd — Suite 112, 88 Queen Street, Sheffield, S1 2FW

support@vatable.co — Document generated 18 March 2026

Powered by TheCarePro.co.uk
© 2026. All rights reserved.

← PreviousInvoicing Next →Opportunities & Pipeline
🔍 Search All Guides