When Orbit cannot safely complete a workflow, it does not pretend it did.
When a workflow cannot complete safely, Blackstar Systems' Orbit says so and follows the recovery behavior configured for that workflow, including Open Dental workflows where they are enabled. It does not hide the failure, guess at the missing result, or treat one fallback path as universal.
Workflows fail for ordinary reasons: a patient can't be found, no slot fits, a system doesn't respond in time. When that happens, Orbit reports the failure rather than papering over it with a guess or a vague reassurance that everything is being taken care of. What happens next, a retry, a stop, or a handoff to a person, depends on how that specific workflow has been configured, not on one universal rule.
Key Facts
- A workflow can stop because inputs, patient identity, availability, or system response cannot be verified.
- Failed or ambiguous outcomes are not reported as success.
- Recovery behavior is configured per workflow and deployment.
- Human follow-up is available only where the client has configured it.
Ordinary operational failures are handled explicitly.
Not every call ends the way it started. A caller's information might not match anyone on file. The provider they want might have nothing open in the window they need. The practice's system might be slow, unreachable, or return something the gateway doesn't recognize as valid. None of these are exotic edge cases; they're the ordinary texture of running a phone line that talks to real, sometimes unreliable systems.
Orbit's job in that moment is narrow: recognize that the workflow can't proceed safely, say so, and hand off to whatever comes next for that specific failure, on that specific deployment. It is not to fill the gap with an answer that sounds complete.
Orbit stops when the workflow cannot be verified.
A workflow can stop because required information is missing, a patient cannot be resolved, no valid availability exists, a connected system cannot complete the action, or the requested workflow is not available for that deployment. In each case, Orbit stops rather than filling the gap with a guess, and follows the recovery behavior configured for that workflow.
What happens after the stop is defined per workflow in that client's configuration. There is not one universal fallback that applies regardless of what failed or which deployment it happened on.
Orbit does not hide failed or unknown outcomes.
Orbit does not present an unresolved outcome as a success to avoid an awkward moment in the call.
It does not assume a single, universal escalation path applies to every failure on every deployment, since recovery behavior is configured per workflow, not fixed globally.
Human follow-up is available where a client has configured it; it is not guaranteed to trigger automatically for every kind of failure everywhere.
A failed workflow is not silently retried an unbounded number of times in the hope that it eventually succeeds.
Surfaced failure is safer than invisible failure.
A system that hides its own failures is more dangerous than one that surfaces them, because the person on the other end of the line has no way to know something went wrong. Naming a failure plainly, and routing it to whatever recovery a client has configured, is what keeps a bad outcome from turning into an invisible one. A caller who hears that something didn't go through can call back, ask for a person, or try again. A caller who's told everything is fine, when it isn't, has no reason to do any of that.
Follow the connected controls.
Common questions about failure and safe recovery.
Does Orbit retry a failed workflow until it works?
No. A failed workflow is not retried without limit, and a retry is not treated as success unless the connected system returns a clear successful result for the operation.
Does every failure automatically create human follow-up?
No. Human follow-up is available only where the client has configured it for that workflow or deployment. Otherwise Orbit follows the configured stop or recovery behavior for that specific case.
See recovery behavior in a live deployment.
Review how failure and escalation are configured on the Open Dental integration.