GoHighLevel automation audit checklist

Most GoHighLevel accounts that "just started doing something weird" were changed by someone, somewhere, for a reason that made sense at the time. An audit finds those changes before you add more. Work through this list with read-only access where you can, write down what you find, and fix nothing until the list is done.

Before you start, create one test contact with an email address and phone number you control, and note the date. You will reuse that contact for every path.

• Every published workflow has a reason to exist. Why: old campaigns keep running long after anyone remembers them. How to check: list published workflows, note each one's trigger and last enrollment, and flag any nobody can explain.
• Trigger filters are as narrow as intended. Why: a "form submitted" trigger with no form filter fires on every form in the account. How to check: open each trigger and confirm the filter names a specific form, tag, pipeline or calendar.
• Re-entry is a decision, not a default. Why: allowing re-entry on a nurture sequence can send the same messages twice. How to check: review the re-entry setting in each workflow's settings and write down why it is on where it is on.
• No two workflows answer the same event. Why: two flows on one trigger send double confirmations. How to check: sort your trigger list by event and look for repeats.

• Each if/else branch has a path for "none of the above". Why: contacts that match no branch silently stop. How to check: open every condition step and confirm the default branch does something deliberate.
• Conditions read fields that are actually filled in. Why: a branch on an empty custom field always takes the same path. How to check: open the test contact and confirm each field a condition reads has a value at that point in the flow.
• Tag names are consistent. Why: "Roof-Lead" and "roof lead" are different tags. How to check: export the tag list and look for near-duplicates used in conditions.

• Every wait has an exit. Why: a "wait for reply" with no timeout holds contacts forever. How to check: open each wait step and confirm a timeout path exists.
• Delays still make sense. Why: a reminder set for a fixed delay drifts when the appointment moves. How to check: prefer waits tied to the appointment time for reminders, and test a rescheduled booking.
• Sending windows match your contact hours. Why: a delay that ends at night sends at night. How to check: review the workflow's time-window settings and run one path late in the day.

• The account, calendar and user timezones agree. Why: a mismatch shifts every booking and reminder. How to check: compare the business profile, each calendar's and each user's timezone settings.
• Nothing quietly rewrites the contact's timezone. Why: a form with its timezone option enabled can overwrite the field on each submission, so reminders render at the wrong local time. How to check: look at a contact's change history for the timezone field and review the timezone setting on each form.
• Reminder text shows the time the customer expects. Why: the calendar can be right while the message is wrong. How to check: book the test contact from another timezone and read the actual text.

• The duplicate-contact rule is known and intended. Why: allowing duplicates splits one person's history across records. How to check: review the account's duplicate-contact setting and search for the test contact after two form fills.
• No workflow triggers itself. Why: a "contact changed" trigger plus an "update field" action can loop. How to check: list workflows that both watch and write the same field, and run the test contact through them.
• Integrations retry without duplicating. Why: a retried webhook or Zap can create a second contact or opportunity. How to check: replay one event and count the records afterward.

• You know where the logs are and who can read them. Why: they explain "it just started doing this" faster than reading every workflow. How to check: open the account's Audit Logs and confirm the right users have access.
• Unexplained field changes are traced to a source. Why: a form, an import, an integration or a user may be writing to the same field a workflow reads. How to check: filter the logs by one affected contact and read the field's change history in order.
• Recent workflow edits are known. Why: the last edit before a problem started is usually the first suspect. How to check: filter by the workflow module and the date the problem began, and compare with each workflow's execution logs and enrollment history.

• Internal alerts reach a real person. Why: alerts to a former employee or an unread inbox mean nobody calls the lead. How to check: list every internal notification step and its recipient, and confirm each recipient is active.
• Assigned-user logic has a fallback. Why: "notify assigned user" sends nothing when no one is assigned. How to check: run the test contact with no owner and see who is told.
• Phone alerts are on. Why: app notifications are often off on staff phones. How to check: ask each recipient to confirm a test alert arrived.

• Availability reflects real capacity. Why: bookings the team can't attend cost more than no booking. How to check: review hours, buffers, minimum notice and date range on each calendar.
• Reminders come from one place. Why: calendar notifications plus workflow reminders send double messages. How to check: compare each calendar's notification settings with the workflows triggered by its bookings.
• Reschedules and cancellations update everything. Why: a canceled booking that still gets reminders confuses customers. How to check: cancel and reschedule a test booking and watch every message that follows.

• First source is captured once. Why: attribution breaks when a later form fill overwrites the source. How to check: check the source fields and attribution on the test contact after two different entries.
• Pipeline stages match how work really moves. Why: stages nobody uses make every report misleading. How to check: look for stages with no opportunities, or with opportunities stuck for months.
• Won and lost are recorded with a reason. Why: without reasons, a lost deal teaches nothing. How to check: sample recent opportunities and confirm a status and a reason are set.

Sort every finding by how many leads it loses, how often it breaks and how cheap it is to fix. Fix in that order, as drafts tested with the test contact before publishing. Keep the list with its date, and run the same checks next month; the GoHighLevel service page describes the same read-only-first process in more detail.