Administration
Permissions
This is the reference for what a permission actually is — the building block behind every row and column in the permission matrix on the Roles page. If you're looking for how to assign roles to people or edit the matrix itself, start there — this page is about what each entry in it means.
How a permission is built
Every permission is a resource paired with an action — for example, Analyses × execute, or Users × manage. A role is just a named bundle of these pairs.
readView the resource and its details.createAdd a new instance of the resource.updateModify an existing instance.deleteRemove an instance.executeRun something — an analysis, a workflow, a model — rather than just read it.manageAdministrative control over the resource, including who else can access it.Resource areas
Not every action applies to every resource — a dataset can be read or updated, but "executed" only makes sense for an analysis, a model, or a workflow.
Analyses
Statistical jobs, saved queries, and their results.
ML
Pipelines, training jobs, models, and predictions.
Datasets
Catalog entries, metadata, and dataset-level access — see Manage Data → Permissions.
Connections & CDC
Data source connections and change-data-capture setups.
Workflows
Multi-step pipelines and their schedules.
Audit
The activity log of who did what, and when.
Users & Roles
The organization's members, roles, and permission matrix itself.
Billing
The organization's plan and billing details.
- Custom roles can mix and match permissions across every resource area — you're not limited to the five system roles' pre-set combinations.
- manage on Users & Roles is what actually lets a custom role edit the permission matrix itself — grant it carefully.
- Permissions here control what a person is allowed to do in general. Which specific datasets they can do it to is a separate, per-dataset setting — see Manage Data → Permissions.