When something needs a human, Orbit flags it instead of guessing.
Not everything a caller asks for has a published workflow behind it, and not everything should be resolved by a conversation alone. When a caller asks for a message to be passed along, or Orbit determines something needs the practice's own judgment, it logs a structured request to that client's queue and alerts the team it configured to receive it. The alert itself carries no caller detail. Whoever receives it has to open Orbit to see what was asked.
Office Messages
A caller doesn't always want a booking or a lookup. Sometimes they want the office to know something: call me back about a billing question, a provider needs to see this before Thursday, someone has a concern that isn't a scheduling matter at all. None of that fits a blueprint, and none of it should be resolved by Orbit deciding on its own what the right answer is.
Instead, Orbit treats it as a message for the practice. It records what was asked, who it came from, and how urgent it seems, then makes sure the right people know a message is waiting. What it doesn't do is put that information anywhere it doesn't need to be. The notification that lands in an inbox says a request came in. It doesn't say what the request was.
Step by step.
The sequence starts the same way every gateway action does: a named intent, not an improvised one. First, Orbit recognizes the caller's request, or its own judgment about the call, as something for the office to review rather than something it can resolve itself. Second, it packages that into a structured record: who called, a message, a category, and an urgency, tied to the specific client the call belongs to.
Third, that record is written to the client's message queue, with duplicate submissions from the same request collapsed rather than logged twice. Fourth, if that client has notifications enabled, an alert goes out to the email addresses configured for it, but the alert is deliberately thin: it says a new request is waiting and links back into Orbit, not what the request says. Fifth, whoever picks it up in Orbit can mark it reviewed, resolve it, or reopen it, so the queue reflects where each request actually stands, not just that it once arrived.
What Orbit will not do.
Orbit does not resolve a message-worthy request on its own; it hands it to the practice rather than guessing at an answer it isn't positioned to give.
It does not include caller details, the message content, or any patient information in the notification email; that only appears once someone logs into Orbit.
It does not send a notification for a client that has alerts disabled, or to an address that hasn't been configured to receive them.
It does not log the same request twice; a duplicate submission from the same call is collapsed into the existing entry, not appended as a new one.
Why It Matters
A caller who says "have someone call me about my bill" isn't asking for a guess, they're asking for a person. Treating that as a request to route, not a question to answer, is what keeps Orbit inside its actual role. And because the practice's team doesn't always check email from a secured device, keeping caller and patient detail out of the alert itself, behind a login, is what keeps a routine notification from becoming a place PHI could leak. The message still reaches the right person quickly. It just doesn't ride along in an inbox that isn't built to hold it.
See how a request reaches your team.
Review how office messages are configured alongside the rest of the Open Dental integration.