A recall loop that logs every message and hears who came back

Whether a patient is due is a formula field in Airtable. The scenario searches a view for rows where 'recall eligible' is true and reads nothing else, so staff change the rule by editing a formula, never a scenario. Two batch scenarios help the formula: one flags records whose medication courses run 60 or 90 days using an aggregate-then-test pattern and a blank-flag work queue, the other links those medications onto the patient by position.

The template id is stored on the patient row by condition, so the wording changes without editing Make. The message carries the patient's first name, title-cased, with a generic fallback.

A daily scenario, capped at 100 patients a run as a limit on rate and blast radius, sends the template, writes a log row (send time, days since the last visit, condition, template, mode, status, replied and booked both No) and stamps the patient's last-recall date, which flips the eligibility formula off so nobody is messaged twice. It then merges a recall tag onto the contact's existing tags rather than replacing them.

If the send fails, the run stops before the log and the stamp, so the patient is still eligible and is retried the next day.

When the messaging system reports that a recalled patient replied or booked, a webhook finds the log row by phone number and sets Patient Replied or Appointment Booked to Yes, with the date. Staff can then see, per recall, who came back.