Workspace Roles Overview
CloudQuery Platform controls access through built-in feature roles, which decide what a user can do, and data access roles, which decide which rows of synced data a user can see. This page describes the built-in feature roles. For data access roles, see Limiting Access to Data.
There are four general-purpose roles (General:Read, General:Write, Admin:Read, Admin:Write) and two special-purpose roles (CI and Schema Only).
Roles are additive, not restrictive. If a user is assigned both Admin:Read and General:Read, they receive the combined permissions of both. To restrict a user, assign only the most limited role they need.
Permissions at a glance
The four general-purpose roles form a gradient: General:Read and Admin:Read are read-only; General:Write adds operational write access (integrations, syncs, policies); Admin:Write adds administration (users, roles, settings, billing, API keys, public reports, and SSO).
| Capability | General:Read | General:Write | Admin:Read | Admin:Write |
|---|---|---|---|---|
| View Asset Inventory data | Yes | Yes | Yes | Yes |
| Run queries in the SQL Console | Yes | Yes | Yes | Yes |
| Save personal SQL queries and filters¹ | Yes | Yes | Yes | Yes |
| Save shared (public) queries and filters | No | Yes | No | Yes |
| Use the AI Assistant | Yes | Yes | Yes | Yes |
| View Insights, Policies, and Reports | Yes | Yes | Yes | Yes |
| View integrations, destinations, syncs, and users | Yes | Yes | Yes | Yes |
| Create, update, and delete integrations, destinations, and syncs | No | Yes | No | Yes |
| Create and manage Policies, Alerts, and custom columns | No | Yes | No | Yes |
| Silence and unsilence Insights³ | No | Yes | No | Yes |
| Manage users, roles, and data permissions | No | No | No | Yes |
| Manage platform settings and billing | No | No | No | Yes |
| Manage notification destinations | No | No | No | Yes |
| Create and manage own private reports² | Yes | Yes | Yes | Yes |
| Create and manage public reports | No | No | No | Yes |
| Create Workspace API keys | No | No | No | Yes |
| Configure SSO / SAML | No | No | No | Yes |
¹ Read roles (General:Read, Admin:Read) can create and edit only their own private queries and filters. Creating or modifying shared (public) ones requires write access.
² Any role can create reports, but only as private reports visible to and managed by their creator. Creating or managing public reports requires Admin:Write.
³ Insight silences are workspace-wide: silencing or unsilencing an insight changes it for everyone in the workspace, not just the acting user. A silence can be indefinite or a timed snooze that re-surfaces automatically. All roles can view silenced insights and list the active silences (and how their resources were selected); only write roles can create, change, or remove them.
Data visibility is enforced separately. Even when a role grants access to a feature, the rows a user sees are filtered by their assigned data access roles.
Built-in Roles
General:Read
The most restricted built-in role. A user with this role can:
- View data in the Asset Inventory
- Create and save their own search filters in the Asset Inventory
- Query data in the SQL Console
- Create and save their own SQL queries in the SQL Console
- Create their own private reports
- Use the AI Assistant
- View Insights, Policies, and Reports
- View the list of integrations, destinations, and syncs and their status
A General:Read user can edit and delete their own saved queries, filters, and reports, but cannot create or modify shared (public) queries or public reports.
General:Write
In addition to General:Read capabilities, a user with this role can:
- Create, update, and delete integrations, destinations, and syncs
- Create and manage Policies, Alerts, and custom columns
- Silence and unsilence Insights (workspace-wide)
- Save shared (public) SQL queries and search filters
A General:Write user cannot perform administrative actions: managing users, roles, or data permissions; changing platform settings or billing; managing notification destinations; creating Workspace API keys; managing public reports; or configuring SSO. Those require Admin:Write.
Admin:Read
A read-only role. It has the same view access as General:Read, including viewing workspace users and Usage in Organization settings, and cannot change any configuration. It is intended for auditors and stakeholders who need visibility without write access.
Admin:Write
The full administrative role. In addition to all General:Write capabilities, a user with this role can:
- Add, update, and delete users
- Manage roles and data permissions
- Manage platform settings and billing
- Manage notification destinations
- Create and manage public reports
- Create Workspace API keys with any role level
- Configure SSO / SAML
Additional Role Types
Beyond the four general-purpose roles, the platform supports these role types:
- CI: The default role for API keys used in automation such as CI/CD pipelines. A CI key can view plugin and integration metadata, manage sync sources, destinations, and syncs, and trigger and monitor sync runs. It has no access to Asset Inventory data, the SQL Console, Reports, or administration features.
- Schema Only: A read-only role that grants access to the schema of Asset Inventory tables (the list of tables and their column definitions) without granting access to the underlying asset data. It is intended for tools and integrations that need to understand the data model but must not read the synced data.
- Custom: Roles created through data access permissions. Custom roles combine data permissions to restrict which data a user can see while granting General:Read-level feature access. For a custom role to take effect, the user must not be assigned any built-in role.
For more on custom roles and data permissions, see Limiting Access to Data.
Programmatic access
Roles and permissions can be managed via the Platform API. See the Platform API Reference (rbac section) for endpoint details on listing, creating, and assigning roles programmatically.
The AI Assistant is only available to signed-in users in the dashboard. It cannot be used with a Workspace API key, regardless of the key’s role.
Next Steps
- Limiting Access to Data - Restrict what data roles can see
- Map Groups to Roles - Automate role assignment with SSO groups
- User Management - Invite and manage users
Last updated on