A completed action is only completed after the connected system confirms it.
Submitting a request is not the same as completing it. Orbit treats an action as done only after the connected system returns a clear, successful confirmation. An attempted write, an ambiguous response, a rejected action, or a failed call are all held as unresolved rather than assumed to have gone through. None of them are shown to a caller as a booked appointment.
Confirmation Boundary
There's a gap between asking a system to do something and knowing that it did. Most of the time that gap closes in well under a second, and it's easy to treat the request and the result as the same event. They aren't. Orbit submits a write, such as creating an appointment, as an attempt.
What comes back from the connected system is a separate event, and it's the only thing that decides whether the caller hears a confirmation. If the system returns a clear success, the appointment is confirmed. If it returns a clear rejection, that's reported as a rejection. If what comes back is ambiguous, incomplete, or doesn't arrive, the honest answer is that the outcome isn't known yet, and that's what gets treated as true, not the more convenient assumption that it probably worked.
Step by step.
After a booking's inputs have been validated, Orbit submits the write to the connected system as a single, attempted action. The system's response is then checked against what a successful confirmation is specifically required to look like for that operation. A response that matches is treated as confirmed, and only then does Orbit tell the caller the appointment is booked.
A response that clearly indicates rejection is reported as a rejection, with whatever reason the system provided. Anything else, a timeout, a partial response, a field missing from what a real confirmation should contain, is treated as unknown. An unknown outcome does not default to success. It routes to whatever recovery or escalation behavior has been configured for that workflow instead.
What Orbit will not do.
Orbit does not tell a caller an appointment is booked based on the attempt alone; it waits for the system's own confirmation.
It does not treat a timeout, an incomplete response, or an ambiguous field as a success by default.
It does not retry a write silently and report the first attempt as though it were the one that succeeded.
A rejected action is reported as rejected, not softened into a delay or a callback promise that implies it will resolve on its own.
Integration-specific mapping for a live deployment lives on the Open Dental integration page, not here.
A false confirmation is a specific kind of failure: the caller leaves believing something exists that doesn't. That's worse for the practice and the patient than a slower, more honest answer, because nobody knows to go back and check. Holding the line at "the system said so, not the attempt alone" is what keeps a fast system from becoming an overconfident one. It also means the practice can trust its own calendar: a slot that shows as booked was accepted by the system of record, not just requested by a caller who assumed it went through.
See confirmation enforced on a live booking.
Review how Orbit and Open Dental confirm a completed appointment.