When something needs a human, Orbit flags it instead of guessing.
Blackstar Systems' Orbit uses office messages for requests that need staff review instead of automated resolution. Orbit records the request inside the client's workspace and sends a thin alert, but the alert does not include caller detail, message content, or patient information.
Not everything a caller asks for has an approved 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 records the request inside the client's workspace and alerts the team configured to receive it. The alert itself carries no caller detail. Whoever receives it has to open Orbit to see what was asked.
Key Facts
- Message-worthy requests are routed to staff instead of answered by guesswork.
- The full request stays inside the client's Orbit workspace.
- Email alerts say a request is waiting but do not expose caller or patient details.
- Duplicate requests are prevented from creating unnecessary repeated entries.
Some caller requests belong with the practice, not the model.
A caller does not 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 is not a scheduling matter at all. None of that fits an approved workflow, 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 the request inside the client's workspace, then makes sure the right people know a message is waiting. What it does not do is put that information anywhere it does not need to be. The notification that lands in an inbox says a request came in. It does not say what the request was.
Orbit stores the request securely and alerts the configured team.
Orbit records the request inside the client's workspace and alerts the people configured to receive it. Duplicate requests are prevented from creating unnecessary repeated entries, and staff can track the request through review and resolution.
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.
Orbit does not put patient detail into email alerts.
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 prevents duplicate requests from creating unnecessary repeated entries.
A useful office alert should not become a PHI leak.
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.