Orbit can only execute approved workflows for the active client.
Reaching the gateway isn't enough for a request to execute. Before anything runs, the gateway resolves exactly which client the request belongs to, whether that client's integration is connected and healthy, what sources are allowed to originate requests for them, and what that specific deployment has been configured and approved to do. Nothing executes against assumed defaults. Every check is resolved against that one client's real configuration, every time.
Bounded Client Scope
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 doesn't treat these as interchangeable.
Before a request gets anywhere near a client's system, the gateway resolves that client's specific identity and pulls up their actual configuration: which integrations are connected, whether the connection is currently healthy, which request sources are permitted for them, and which providers, operatories, and workflows have been set up and turned on. A deployment that hasn't approved a given workflow doesn't have access to it, regardless of what Orbit's conversational layer might otherwise be capable of requesting.
Step by step.
Client scoping happens before anything else runs. First, the gateway resolves the client token attached to the request into an actual client identity, not a label the conversation supplied. Second, it checks whether that client's integration is currently connected and reachable; a disconnected or unhealthy integration stops the request there. Third, it checks the request's source against that client's allowed sources, since a request from an unexpected origin is treated differently than one from an approved channel.
Fourth, it loads that client's provider and operatory configuration, so a request can only reference resources that exist for that practice. Fifth, it checks whether safe mode is active for that client, which can block writes outright regardless of everything else being valid. Only once every one of those resolves cleanly does a request reach the point where a published blueprint gets evaluated.
What Orbit will not do.
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 safe mode when it's active 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.
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.
See scope resolved against a real deployment.
Review how client-specific configuration plays out on the Open Dental integration.