Planned resources
| Resource | Purpose |
|---|---|
| Workspace profile | Company identity and workspace metadata. |
| Members | People with access to the workspace. |
| Roles and permissions | Access boundaries for settings, inbox, automations, and context. |
| Tags | Managed labels for conversations, issues, and accounts. |
| Custom fields | Structured context fields for customers and conversations. |
| Macros | Reusable replies and workflow actions. |
| Automations | Rules that tag, route, delay, or annotate support work. |
| Channel settings | Workspace-level channel configuration. |
Common use cases
Sync team membership
Keep support access aligned with another internal system.
Mirror CRM fields
Align tags or custom fields with your source of truth.
Manage support content
Keep macros and labels aligned with product documentation.
Build admin tooling
Create internal dashboards around workspace configuration.
Boundaries
Workspace administration APIs should require strong authentication and the right scopes. They should not be available through widget public keys. Do not expose:- Provider routing internals.
- Service-role details.
- Hidden model settings.
- Operator-only debug traces.
- Private customer data from another workspace.
Readiness criteria
- Role and permission behavior is stable.
- Writes are auditable enough for customer admins.
- No-op saves do not grant unnecessary write access.
- Table-backed resources preserve workspace ownership.
- Public responses avoid internal-only configuration.