> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/data/workspaces.md). # Workspaces Tenant isolation boundaries with separate world models, data sources, voice configs, and role-based access control. A workspace is the tenant boundary in the Concurrence platform. Each workspace has its own world model, connected data sources, agent and service configurations, and access settings. Public data access is authenticated and scoped to the selected workspace. ## Tenant Isolation ```mermaid %%{init: {"theme":"base","fontFamily":"Inter, sans-serif","themeVariables":{"fontFamily":"Inter, sans-serif","fontSize":"16px","background":"#FAF8F6","primaryColor":"#F1EAE7","primaryTextColor":"#1A1817","primaryBorderColor":"#D7D2D0","secondaryColor":"#FDFCFB","tertiaryColor":"#F6F2F0","lineColor":"#575452","textColor":"#3D3937","clusterBkg":"#FDFCFB","clusterBorder":"#E8E2DF","edgeLabelBackground":"#FAF8F6","actorBkg":"#F1EAE7","actorTextColor":"#1A1817","actorBorder":"#D7D2D0","actorLineColor":"#575452","signalColor":"#575452","signalTextColor":"#3D3937","labelBoxBkgColor":"#F1EAE7","labelBoxBorderColor":"#D7D2D0","labelTextColor":"#3D3937","loopTextColor":"#3D3937","noteBkgColor":"#F6F2F0","noteBorderColor":"#D7D2D0","noteTextColor":"#3D3937","activationBkgColor":"#F1EAE7","activationBorderColor":"#D7D2D0","altSectionBkgColor":"#FAF8F6","altSectionColor":"#3D3937"}}}%% flowchart TB subgraph WA["Workspace A"] WMA[World Model] --- SA[Services] SA --- PA[Phone Numbers] PA --- DA[Data Sources] end subgraph WB["Workspace B"] WMB[World Model] --- SB[Services] SB --- PB[Phone Numbers] PB --- DB[Data Sources] end WA ~~~ WB style WA fill:#FDFCFB,stroke:#D7D2D0 style WB fill:#FDFCFB,stroke:#D7D2D0 ``` Each workspace is an isolated organizational boundary. This means: * Workspace-scoped event reads do not expose another workspace's events * Entity projections are computed per-workspace * Phone numbers, services, and context graphs are scoped to a workspace * API keys authenticate to a specific workspace ### Layered Isolation Public requests authenticate a workspace identity, validate that referenced resources belong to that workspace, and scope supported reads and writes to the same tenant. Data services add storage-level controls where appropriate, while audit records retain workspace and actor attribution. Some trusted platform workers intentionally process more than one workspace, such as schedulers and connector workers. Those paths use service credentials and preserve explicit workspace scope; they are not public unscoped access. Treat isolation as a layered authorization contract rather than assuming every table uses one identical enforcement mechanism. For healthcare organizations, this isolation model supports multi-site deployments where each clinic, department, or practice operates as its own workspace with its own data and configuration. A hospital system with five clinics can run five workspaces, each with its own EHR connector, phone numbers, and scheduling logic. ## API Keys and Permissions API access is scoped to an account within a workspace. Each account has a role that determines what it can do: | Role | Capabilities | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Owner** | Admin permissions plus the ability to create owner-role API keys. | | **Admin** | Can update and delete workspace resources, manage members and API keys, query privileged analytics, view audit data, and delete a workspace. | | **Member** | Read access plus supported resource creation, clinical data writes, outbound conversation starts, channel sends, and trigger management. | | **Operator** | View access plus operator actions: monitor and take over eligible runs, send guidance, author supported text turns, and claim or decide external write proposals where the private-preview review flow is enabled. | | **Viewer** | Read-only access. Can view configurations, data, and call records but cannot modify anything. | When creating an API key, the caller selects a role and may optionally narrow it to a subset of that role's permissions. The requested role and permissions cannot exceed the creator's own access, and only an owner can create an owner-role key. ## Environment Separation {% hint style="warning" %} Never test agent behavior changes directly in a production workspace. Use staging workspaces to validate changes before promoting them to production. {% endhint %} Use separate workspaces for different regions and stages of delivery: | Environment | Purpose | | --------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Production** | Live workloads and production integrations. | | **Staging** | Pre-production testing with production-like configuration. | | **Development** | Building and testing new context graphs, skills, and integrations, typically with synthetic data or sandbox integrations. | This separation ensures that changes to agent behavior, safety rules, or data integrations can be tested in staging before they affect real patient interactions in production. The current Platform API does not expose workspace environment conversion or an editable environment label. Production, staging, and development describe how the team uses and provisions its separate workspaces. Confirm the actual session, data-access, retention, and integration policies for each deployment; naming a workspace staging or production does not change those controls. ## Optional Data Exposure Workspace administrators can request two separate capabilities: topic modeling and Delta Sharing. Both are disabled by default. Topic modeling enables eligible classification and its provisioned data views. Delta Sharing exposes the selected workspace datasets to a configured recipient; it is not permission to browse other workspaces or a copy of every internal table. Delta Sharing supports an open-sharing recipient or a Databricks recipient identified by its sharing identifier. Confirm the selected mode and recipient during provisioning. Saving the setting and applying the underlying grants are separate steps, so verify provisioning and recipient access before consuming data. Disabling exposure or changing an active recipient requests access reconciliation. If that request cannot be queued, the API reports a failure even though the setting was saved. Retry and verify that access was revoked; do not treat the stored flag alone as proof of revocation. Previously downloaded data remains subject to the recipient's own handling policy. See [Delta Sharing](https://docs.concurrence.com/developer-guide/classic-api/data-access/delta-sharing) for the supported setup and consumption workflow. ## What Lives in a Workspace A workspace contains all the resources needed to run a deployment: * **Services** - Define which context graph and agent configuration handle calls * **Phone numbers** - Routed to services within the workspace * **Data sources** - Configured EHR, FHIR, database, file, and API integrations plus connector runner settings * **World model** - The event store and entity projections for this workspace * **Agent configuration** - Authored behavior, context graphs, models, functions, and channel-specific settings * **Voice settings** - TTS voice selection, speed, keyterm lists, sensitive topic configuration * **Operator configuration** - Which operators can join calls and how escalation works * **Security settings** - Optional workspace-level security controls and access policies {% hint style="info" %} **Developer Guide** - For API endpoints, SDK examples, and integration details, see the [Workspaces](https://docs.concurrence.com/developer-guide/platform-api/workspaces) section of the developer guide. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.concurrence.com/data/workspaces.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.