A durable appointment reminder workflow stores the next valid send date as CRM state, updates it after schedule changes, and checks eligibility again before sending.
An appointment reminder workflow can look correct in the builder and still send the wrong message. Trouble starts after the happy path: a customer cancels, moves the appointment, or books another service while an old reminder is already waiting. If the automation treats "wait 21 days" as its source of truth, it can act on a schedule that no longer exists.
A safer design stores the next valid reminder date as business state. Appointment changes update that state, and the workflow checks it again immediately before sending. The result is a small system that can explain when a reminder should run, when it should stop, and which appointment it belongs to.
A fixed delay answers one narrow question: when should this workflow execution wake up? It does not answer the more important one: should the reminder still be sent when it wakes up?
Consider a weight-loss clinic that wants to remind a patient to book again 21 days after a completed appointment. On day 10, the patient could cancel the follow-up plan, book a new appointment independently, or become ineligible for that service. The original workflow execution may still be sleeping. Unless something reevaluates the contact on day 21, the message can be perfectly timed and operationally wrong.
Workflow enrollment is temporary. The CRM record lasts. PASMO's view is that a delayed action with a meaningful cancellation or replacement path should run from explicit CRM state, rather than the age of one workflow execution.
Split the automation into two responsibilities.
The first workflow is the state writer. It reacts to appointment events and calculates what should happen next. When a qualifying appointment is completed, it writes a field such as next_booking_reminder_at. When the appointment is canceled, replaced, or no longer relevant, it clears or recalculates that field.
The second workflow is the sender. It starts from the stored date, checks current eligibility, sends the message once, records the result, and then clears or advances the date.
HighLevel has native pieces for this split. Its Custom Date Reminder trigger can start a workflow before, on, or after a selected date field. Its Appointment Status trigger can react when an appointment is scheduled or its status changes. These features put scheduling state on the contact record, where another event can inspect and change it.
A minimal contact record can look like this:
{
"next_booking_reminder_at": "2026-09-17T14:00:00-04:00",
"reminder_reason": "weight_loss_follow_up",
"source_appointment_id": "apt_4821",
"reminder_status": "scheduled",
"last_reminder_key": null
}The source appointment ID matters. Without it, a later appointment update can overwrite or clear a reminder without proving which appointment created it.
A workflow is much easier to review when its transition rules exist outside the canvas. A useful first version needs only six:
scheduled.source_appointment_id matches the changed appointment.sent.This sequence prevents a common multi-appointment bug. If one contact has two appointments, a cancellation event for appointment B must not erase the reminder created by appointment A. Matching the stored source ID draws that boundary.
HighLevel's documented appointment behavior is useful here. A cancellation can pull a contact out of an appointment workflow. A reschedule can do the same, then permit re-entry when the trigger matches and Allow Re-entry is enabled. That handles appointment-relative sequences. A reminder scheduled weeks after a completed visit still needs its own business state.
The date trigger should lead to an eligibility check, not directly to "Send SMS."
When the date arrives, verify that the reminder is still populated and due, its status is scheduled, the reason matches the intended service, no qualifying future appointment already exists, and the same reminder key has not been completed before. If a check fails, exit without sending and write a reason that an operator can inspect.
A practical idempotency key can combine the contact, reason, and scheduled date:
contact_9172:weight_loss_follow_up:2026-09-17Store that key before the send request, or atomically with it when the platform allows. If the provider times out after accepting the message, a retry should reuse the key instead of creating a second logical send.
The past-date path also needs an explicit choice. HighLevel's Wait action supports dynamic dates and several behaviors when a date has already passed, including continuing, exiting, or jumping to another step. Blindly continuing can turn a bad import into an immediate outbound message. Unless the business has approved catch-up sends, route past-due records to a validation branch.
One fresh appointment and one delivered message prove very little. Use a short test run built around the failure paths:
The acceptance criterion is more demanding than "the message arrived." The CRM should show why the reminder existed, which appointment created it, why it was sent or suppressed, and whether a retry duplicated the action.
A cancellation-safe appointment reminder workflow takes more work than adding a delay after an appointment, but it is easier to trust. If your CRM sends stale reminders or nobody can explain which execution owns the next message, PASMO can help redesign the state model and test the failure paths before customers find them.