Start with its recurring appointment limitations, then trace the missing visit from calendar record to send attempt.
Key Takeaways
- Identify the booking method before editing reminder automation.
- Record evidence for each occurrence, including later and changed visits.
- Separate missing workflow entry from a send failure or uncertain delivery.
Which kind of recurring appointment did the client create?
Ask the person who made the booking to show the original path. A calendar with recurrence enabled and a custom series entered by a staff member should not be treated as interchangeable.
HighLevel’s Recurring Appointments guide distinguishes calendar rules used by the booking widget or the Default Date & Time tab from rules entered through the Custom tab. Custom rules override the calendar configuration. For that custom path, later occurrences also do not appear individually in Appointment List, Contacts or Conversations views.
Record the booking route, calendar name, contact, series start and intended future visits. Use the calendar to inspect the occurrence you are investigating rather than relying only on the contact timeline. Capture the recurrence settings before changing anything so the agency can reproduce the client’s original setup.
A useful support question is: “Show me the visit that missed its reminder and how you created it.” That produces more actionable evidence than “Are recurring appointments enabled?”
Is the workflow trigger eligible for this booking?
Check the exact trigger name and filters. Similar appointment labels do not establish that the automation supports the booking being tested.
HighLevel’s Customer Booked Appointment documentation says that trigger supports regular appointments booked independently by the customer. It excludes recurring appointments and bookings made manually by staff. A successful message from some other booking path does not validate this trigger for the series.
For calendar-level recurrence, HighLevel’s recurring calendar configuration guide describes Appointment Status event filters: Normal excludes recurring appointments, Recurring targets appointments booked on calendars with recurrence enabled, and Any includes either type. The guide also distinguishes booking sources through Modified By filters.
In a test copy of the workflow, inspect the calendar, appointment status, event type and booking-source conditions together. Match them to the event you intend to handle. Avoid broadening every filter at once: if unrelated appointments start entering, the test no longer isolates the original problem.
Then create a fresh test booking through the same route as the client. Keep the workflow name and configuration alongside the observed result. Treat a matching filter as a candidate fix until a later occurrence actually passes the test.
What should you inspect on each appointment record?
Start with whether the intended visit exists and what its current details say. A repeating pattern on a calendar is not sufficient evidence that your reminder automation has the correct appointment context.
For calendar-configured recurrence, unavailable-slot settings can skip a booking, continue booking or seek another available slot. Compare the expected visit with the actual calendar result before diagnosing a missing reminder. These options are documented in HighLevel’s calendar recurrence guide.
For each visit under review, record:
- The appointment identifier, if available, and the date you are inspecting.
- The client location, calendar and contact attached to it.
- Its current status, start time and timezone.
- The reminder’s intended send time and message content.
- Any edit, cancellation or reschedule that happened after booking.
Compare the appointment details with the workflow execution evidence. Look for the relevant entry and the path toward the reminder action. If the contact entered, inspect waits, conditions and exits before investigating the messaging provider.
If evidence is missing, mark it unknown. Do not fill the gap using the date of the first visit or a successful text from another workflow. That shortcut can hide a stale reminder pointing to the wrong appointment.
How do you separate an absent trigger from a delivery failure?
Use the last confirmed stage to decide what to investigate next. This is a diagnostic method, not a claim that every account exposes identical logs.
| Evidence found | Working diagnosis | Next check |
|---|---|---|
| Intended visit cannot be found | Booking or record visibility needs review | Booking route and calendar occurrence |
| Visit exists, no matching workflow entry found | Trigger or enrollment needs review | Trigger eligibility and filters |
| Workflow entered, sending action not reached | Workflow path needs review | Wait, branch, exit and current appointment context |
| Sending action ran, request rejected | Send request needs review | Recorded error and integration configuration |
| Request accepted, receipt unconfirmed | Delivery remains unresolved | Message status and controlled recipient check |
Keep acceptance and receipt separate. A provider accepting a request does not prove that the customer’s phone received it. Likewise, no provider message record may mean the workflow never requested a send; it does not establish filtering by a carrier.
Write the support finding in concrete terms: “The later visit has no matching workflow execution in the records checked.” That gives the next person a starting point without declaring an unsupported platform bug.
What should an occurrence-by-occurrence test sheet contain?
Create a sheet for a controlled test contact before connecting the reminder path to live client messaging. The table below is a blank test plan, not a report of completed results. Fill each evidence cell from the account under review.
| Test case | Mode and appointment record | Trigger and expected send | Observed result |
|---|---|---|---|
| Initial visit | Booking route, identifier, date | Trigger, filters, reminder time | Entry, action, message status, receipt |
| Next scheduled visit | Same fields for this occurrence | Expected appointment context | Entry, action, message status, receipt |
| Later future visit | Confirm actual calendar record | Expected reminder time and content | Entry, action, message status, receipt |
| Rescheduled visit | Updated date and affected scope | New reminder due; old time reviewed | Actual reminder and stale-send check |
| Canceled visit | Current status and affected scope | No active reminder expected | Suppression evidence and owner |
Choose future test dates that leave room for the reminder window. Use phones controlled by your team and a clearly labeled test calendar. Keep the original workflow settings available for comparison.
Run the booking normally rather than relying entirely on manual enrollment. Manual entry can help inspect actions, but it does not test whether the appointment event qualifies for the trigger.
For changes, record exactly which occurrence or series scope you selected. Check both the updated visit and any reminder still tied to its former time. Require a clear result for each planned test case before copying the configuration to another client account.
When should you connect the verified reminder path to Beam?
Connect the messaging step after you can explain how each intended occurrence reaches it. The GoHighLevel iMessage workflow guide describes the Custom Webhook path; the regular GoHighLevel Send SMS action continues through the default SMS provider.
Validate the request in a dry run, then perform a controlled live send. Keep the appointment reference with the request and resulting message record. Use a send key that distinguishes each intended reminder while remaining stable for retries of that same message, following the linked guide.
Test the recipient side separately. The Android messaging guide explains why channel selection and delivery status need separate checks. Record what arrived on the test phone and whether its reply appears against the intended contact.
For reseller handover, the agency messaging rollout guide helps define who owns ongoing operation and exceptions. Give that owner the completed occurrence sheet, workflow name and unresolved cases.
If the client also uses RizzDial calling for GoHighLevel, apply the same appointment checks to the call handoff. A missing reminder event should not silently become a reason to call the customer.
What else do agencies ask about recurring reminders?
Does Customer Booked Appointment support recurring visits?
No. HighLevel documents this trigger for regular appointments booked independently by the customer. Recurring appointments and manual staff bookings are outside its supported scope. Review the booking method before choosing a replacement trigger.
Will changing the Event Type filter fix custom recurrence?
Do not assume so. The recurring calendar filter guidance and the custom recurrence limitation describe different paths. Test the actual booking method and require evidence for a later occurrence before approving the workflow.
Should I add a repeating delay to replace missing triggers?
Avoid treating a repeating delay as proof of appointment awareness. A reminder plan must account for current visit dates, cancellations and series changes. Test those cases before relying on a repeating schedule.
Can a messaging integration fix an absent appointment trigger?
A messaging integration needs a valid send instruction. First establish that the intended occurrence reaches the sending action, then inspect the provider response and recipient result. Changing the delivery channel alone does not establish that workflow entry occurred.