> 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. 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 integration, 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 decide conversation-scoped integration approvals. | | **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** - Stored data-source records; the platform does not poll them * **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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` 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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.