Tomorrow's appointments, copied from one system into another
Two Make scenarios copy tomorrow's appointments from a medical-records system into the scheduling system, one branch per site, and backfill each patient's scheduling-system contact id by phone number.
Where this applies
Any business with a records system and a separate booking or messaging system that must agree about tomorrow's appointments.
- sites, one identical branch each
- 3
- modules in the appointment sync
- 27
- scenarios, both switched off
- 2
The problem
When appointments live in one system and reminders and booking views live in another, the two have to agree, or the wrong people are reminded and the calendar tells a different story from the records.
A copy has to find the right practitioner and contact on the far side, tolerate a person it has not met before, and carry a key that lets a re-run recognise what it already copied.
What we built
One day, one branch per site
The sync works out tomorrow's date, then splits into three identical branches, one per clinic location. Each lists that location's appointments for that single day, which keeps responses small, and iterates them.
A spreadsheet staff can maintain
The records system names a doctor; the scheduling system needs a specialist id. A Google Sheets lookup matches the doctor's name, case-insensitively, to the id (kept in a sheet so non-developers can maintain the mapping) and a fixed fallback specialist means no appointment is dropped when a name is missing.
Contact by phone, and an external id
Each patient's contact is looked up in the scheduling system by phone number. The appointment is then created with the source appointment id as its external id, the intended key for recognising a copy on a re-run, with duration computed from start and end and a note carrying the status and doctor.
A queue for the contact ids
A batch scenario gives each patient row the matching contact id from the scheduling system, found by phone and flagged present. The flag is the work queue, so a matched patient drops out of the next run.
The outcome
Built in June 2026 as one scenario of 27 modules, with the contact backfill alongside it from January.
Both are switched off and have no retained run history, so this page describes a design rather than a volume.
Where it stops
If the contact lookup finds nobody (a patient new to the scheduling system), the create request is malformed and the run fails. The contact is matched by phone alone, so a shared number could attach the wrong person. Locations, services and the fallback specialist are fixed in the scenario, the same branch exists three times so a change must be made three times, and whether the target system enforces the external id is not visible from the scenario. The contact backfill retries unmatched patients every run and, for a shared phone, keeps the last contact found.
Built with
- Make.com
- Airtable
- Google Sheets
- Make data store
- HTTP API
Patterns used
- One day, one window
- Mapping kept in a sheet
- External id as the copy key
- Flag as work queue
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no