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

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

Never test agent behavior changes directly in a production workspace. Use staging workspaces to validate changes before promoting them to production.

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 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 connector runner that polled them was retired on October 10, 2026
• 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

Developer Guide - For API endpoints, SDK examples, and integration details, see the Workspaces section of the developer guide.