Team Permissions

The Timeline rows in this table cover containers, quality checks, and anomalies, which are scoped by datastore teams. A check template also has a Timeline, but a template does not belong to a datastore, so team permissions do not apply there: any user with the Member user role (or higher) can read a template's Timeline, comment, reply, and manage their own comments, even a user whose team permission is Reporter. ↩

Deleting another user's comment requires the Admin user role, which is not bound by team permissions. Editing another user's comment is never allowed, for anyone. ↩↩

In addition to the Author team permission on the anomaly's datastore, linking or unlinking an external ticket also requires the platform-wide Manager user role (or higher). Users with only the Author team permission but a Member user role cannot use the ticket link/unlink actions. ↩

An AI Use Case has no teams of its own. It derives every permission from the datastores it binds, and the requirement must hold on all of them - a use case spanning three datastores is only as accessible as its weakest binding. A user who loses access to one bound datastore stops seeing the use case entirely, rather than seeing a partial and misleading view of its governed inputs. Binding a container or a quality check is governed by the permission on that asset's datastore. ↩

Authoring an AI Use Case follows the same hybrid ownership model as Computed Assets. A user with the Member user role and the Author team permission can create use cases and edit, delete, baseline, and generate evidence for the ones they own; the Manager and Admin user roles can author any use case, provided they hold Author on every bound datastore. Ownership is set at creation and never changes. Creating a use case with nothing bound yet still requires Author on at least one datastore. ↩↩

Certifying or revoking is gated at both layers, like datastore creation. It requires the Manager user role (or higher) plus the Editor team permission on every bound datastore. The Manager user role alone does not bypass the team permission. This is deliberately not an authoring permission: an Author submits their work for review, and a Manager of the data signs it off. See AI Use Cases for the certification lifecycle. ↩

Creating a datastore is gated at both layers. It requires the Manager user role (or higher) plus the Editor team permission on at least one team the new datastore is assigned to (the Public team when none is chosen). No team permission grants it on its own, and the Manager role alone does not bypass the team permission: a Manager whose teams all sit below Editor cannot create datastores. The same rule applies to the multi-schema flow; see Multiple-Schema Permissions. ↩

Editor is the only permission that reveals masked values without restriction, and it is required on every reveal surface: Anomaly Source Records, Quality Check Dry Runs, Field Profile histograms, and Export/Materialize outputs. Data Preview is the single exception: there, an Author can also reveal the masked fields that are Computed Fields they own. Any other masked field in that same preview stays masked, and the reveal is recorded in the masking audit log exactly like an Editor's. An Author with no owned masked computed field in the container cannot reveal anything. ↩