Permissions
Access to a Computed Field is governed by two independent controls: the user's platform-level role (Member, Manager, Admin) and the team permission they hold on the parent datastore (Reporter, Viewer, Drafter, Author, Editor). Every action requires the caller to satisfy both.
The Team Permissions overview is the canonical matrix for what each team permission grants across the platform. This page mirrors that matrix for the actions specific to a Computed Field, and calls out one refinement (the Hybrid Gate) that widens the Editor-only rule for computed assets.
Roles vs Team Permissions
- User role: assigned when the user is created. Every action described below requires at minimum the Member role. The Admin role bypasses every team-level check on this page. The Manager role does not bypass; Managers follow the same team-permission rules as Members.
- Team permission: assigned per user per datastore, either directly or through team membership. Computed Fields inherit their parent datastore's team permissions; there is no separate ACL at the field level.
Action Matrix
Legend:
- The permission grants the ability to perform the action
- The permission does not grant the ability to perform the action
| Action on a Computed Field | Reporter | Viewer | Drafter | Author | Editor |
|---|---|---|---|---|---|
| Field | |||||
| View the Computed Field (details, profile, tags, history) | |||||
| List Computed Fields inside a container | |||||
| Preview data (sample rows) | |||||
| Create a Computed Field[^hybrid] | |||||
| Edit a Computed Field[^hybrid] | |||||
| Delete a Computed Field[^hybrid] | |||||
Reassign ownership (change owner_id) |
|||||
| Assign tags to the Computed Field[^hybrid] | |||||
| Operations | |||||
| View activity, operations, logs, and results | |||||
| Trigger a profile or scan operation on the container | |||||
| Quality Checks | |||||
| View quality checks that target the Computed Field | |||||
| Create a draft quality check | |||||
| Save or restore a check to draft | |||||
| Create or edit an active quality check | |||||
| Activate or validate a quality check | |||||
| Archive or delete a quality check | |||||
| Anomalies | |||||
| View anomalies on the Computed Field | |||||
| View anomaly source records | |||||
| Change anomaly status (Acknowledge / Archive) | |||||
| Add a comment to an anomaly |
[^hybrid]: Computed Fields (and other computed assets) also honor a Hybrid Gate: an Author may Create the Computed Field when owner_id is omitted or set to their own user id, and may Edit or Delete a Computed Field they currently own. Editor bypasses this gate. See the section below.
Users with the Admin role bypass every entry in this table and can perform every action regardless of their team membership.
The Hybrid Gate
Create, Edit, and Delete of a Computed Field follow a hybrid gate that widens the Editor-only rule for regular (non-computed) fields. The caller either holds Editor on the parent datastore, or holds Author and is the field's current owner (for Edit and Delete) or will be its owner (for Create, when owner_id is omitted or set to their own user id). The relaxation lets Authors govern the Computed Fields they own without needing full Editor on the datastore.
Two consequences worth remembering:
- An Author cannot create a Computed Field and assign it to another user in the same request. The create is allowed only when
owner_idis omitted or set to the Author's own user id. - Reassigning ownership after the fact (setting
owner_idto a different user on Update) always requires Editor, even when the caller is the current owner.
The Hybrid Gate applies to computed assets (Computed Fields, Computed Tables, Computed Files, Computed Joins). Regular fields on a container continue to require Editor uniformly for Create, Edit, and Delete.