Patient-specific workflows start with patient identification.
Scheduling only starts once two things are true: the patient has been identified, and the connected system has returned real availability for that specific request. Orbit does not proceed on a guess in either direction. An unresolved patient, an ambiguous match, or an empty availability response is treated as a stop, not a placeholder to work around.
Identity, Availability, and Booking
A booking involves two claims agreed on at once: this patient, and this provider at this time. Orbit is careful about both before it lets a workflow continue. On the patient side, that means resolving a caller to a specific, identified record using the details a workflow collects, not proceeding on a name alone or a rough match that could belong to more than one person.
On the scheduling side, it means asking the connected system what's open, for the actual provider, operatory, and duration the workflow requires, rather than assuming an hour is available because it typically would be. Both checks have to clear before a time is offered to the caller, and both are re-checked, not assumed to still hold, at the moment the appointment is submitted.
Step by step.
The sequence runs in a fixed order. First, Orbit collects the identifying details a workflow requires and sends them to the connected system to resolve a specific patient record. A clean single match lets the workflow continue; more than one plausible match, or no match at all, does not.
Second, once a patient is resolved, Orbit requests availability from the system of record for the specific provider, operatory, and duration the workflow calls for. The times it can offer a caller are only ever the times that specific request returns, not a general sense of when the practice tends to be open. Third, a booking is only submitted once both the patient and the specific slot have been confirmed as valid in that same conversation, since either one can change between when it was first checked and when the caller is ready to commit.
What Orbit will not do.
Orbit does not create or select a patient record from a partial or ambiguous match; an unresolved identity stops the workflow rather than proceeding on a best guess.
It does not offer a time that wasn't returned by the connected system's own availability check, and it does not assume a slot is still open after checking it once.
It does not support canceling or rescheduling an existing appointment as part of this flow.
Integration-specific detail, such as exactly which fields identify a patient for a given practice-management system, lives on that system's own integration page, not here.
Integration-specific mapping for a live deployment lives on the Open Dental integration page, not here.
Getting the patient wrong means writing information against the wrong record. Getting availability wrong means telling a caller they have an appointment that doesn't exist. Both failures are worse than simply being slow, because they look successful right up until someone discovers otherwise. Requiring a resolved identity and a system-confirmed slot before anything moves forward is what keeps a booking from becoming a confident-sounding mistake. For a practice, that mistake would otherwise surface later as a double-booked chair, a record with someone else's history attached to it, or a front desk untangling a call that sounded fine at the time.
See identity and availability resolved live.
Review how patient lookup and scheduling work on the Open Dental integration.