Orbit can only execute approved workflows for the active client.
Bounded client scope means Blackstar Systems' Orbit can act only inside the active practice's approved configuration, including connected systems such as Open Dental. The same platform may support multiple workflows, but a deployment can use only the integrations, providers, operatories, locations, and write controls enabled for that client.
Reaching the gateway is not enough for a request to execute. Before anything runs, Orbit resolves the active practice and evaluates the request against that practice's actual configuration. Nothing executes against assumed defaults. Every check is resolved against that one client's real configuration, every time.
Key Facts
- The active practice is resolved before a workflow can run.
- Enabled integrations and workflows are checked per deployment.
- Provider, operatory, location, and write controls stay client-specific.
- Unsupported or unconfigured cases are blocked rather than approximated.
Each practice's configuration is treated as its own boundary.
No two clients run a practice the same way. One office has three providers and two treatment rooms; another has twelve providers across two locations. One has enabled appointment creation; another has only enabled availability lookups while it evaluates the system. Orbit does not treat these as interchangeable.
Before a request gets anywhere near a client's system, Orbit checks it against that client's specific configuration: which integrations and workflows are available, and which providers, operatories, and other practice resources are in scope. A deployment that has not approved a given workflow does not have access to it, regardless of what Orbit's conversational layer might otherwise be capable of requesting.
Orbit checks client scope before continuing.
Before an action can run, Orbit resolves the active practice and evaluates the request against that practice's actual configuration. The connected integration must be available, the requested workflow must be enabled, and any referenced practice resources must belong to that deployment. If the request falls outside those boundaries, it is blocked rather than approximated.
Client-level controls can also disable write operations regardless of what the conversation requests. Only after those boundaries are satisfied can the approved workflow continue.
Orbit cannot borrow scope from another deployment.
Orbit cannot execute a workflow that hasn't been explicitly enabled for the client on the call.
It cannot reference a provider, operatory, or location that isn't part of that client's configuration, even if a similar one exists for a different client.
It cannot bypass client-level controls that disable write operations for that deployment.
It does not fall back to a default configuration when a client's specific setup doesn't cover a request; an unconfigured case is treated as unsupported, not approximated.
Client scope keeps one deployment from inheriting another's permissions.
Treating every client the same would mean either overpromising to a smaller practice or under-constraining a larger one. Resolving scope per client, on every request, is what lets a single-location practice and a twelve-provider group run on the same underlying system without either being exposed to capability they never approved. It also means a configuration mistake or a disabled workflow shows up as a blocked request, not one that quietly executes against the wrong assumption.
Follow the connected controls.
Common questions about bounded client scope.
Can Orbit use another practice's provider, operatory, or workflow if the caller asks for it?
No. Orbit resolves the active practice first, then checks the request against that practice's own approved providers, operatories, locations, integrations, and workflows. A similar resource on another deployment is not available to the caller.
What happens when a practice has not enabled a write action?
The write action is blocked for that deployment. Orbit does not treat platform-level capability as client approval, and it does not fall back to a default configuration when a workflow is not enabled.
See scope resolved against a real deployment.
Review how client-specific configuration plays out on the Open Dental integration.