Permissions
Computed Joins are gated by a hybrid permission model: a user's team permission on the datastore the join belongs to, plus ownership of the Computed Join itself. Editors on that datastore can manage any Computed Join. Authors can manage only the Computed Joins they own. Reading the joined output requires at least Reporter on that datastore.
Which datastore the join belongs to
In pairwise mode the join belongs to the left container's datastore. In SQL mode it belongs to the first source's datastore, captured when the join is created. That datastore does not change later, even if you point the first source at a container somewhere else.
SQL mode adds one more requirement: because sources can span datastores, you need at least Viewer permission on every source's datastore, not just on the one the join belongs to.
Two Permission Systems
Qualytics has two separate access systems. User Roles (Member, Manager, Admin) control what a user can do across the entire workspace. Team Permissions (Reporter, Viewer, Drafter, Author, Editor) control what a user can do on specific datastores they have access to through team membership. A user needs the right combination of both to manage a Computed Join.
Permissions on the Join's Datastore
Most checks run against the team permissions on the datastore the Computed Join lives under.
| Action | Reporter | Viewer | Drafter | Author | Editor |
|---|---|---|---|---|---|
| View the Computed Join (profile, anomalies, fields) | |||||
| View the Timeline and open the Query Diff dialog | |||||
| Create a Computed Join with yourself as the owner | |||||
| Create a Computed Join with another user as the owner | |||||
| Edit a Computed Join you own | |||||
| Edit a Computed Join owned by another user | |||||
| Delete a Computed Join you own | |||||
| Delete a Computed Join owned by another user | |||||
| Reassign the owner to another user | |||||
| Modify quality score settings on a join you own | |||||
| Modify quality score settings on a join owned by another user | |||||
| Run a Scan, Profile, or Materialize against the joined output |
For the full reference of team permissions and how they are assigned, see Team Permissions Overview.
Admin Bypass
Users with the Admin user role bypass all team-permission checks and can create, edit, and delete any Computed Join, regardless of team membership or ownership.
Permissions on Other Datastores (Cross-Datastore Joins)
When an input lives in a different datastore from the join's own, the platform also checks the user's team permission on that datastore: the right datastore in pairwise mode, or each source's datastore in SQL mode.
| Action | Reporter | Viewer | Drafter | Author | Editor |
|---|---|---|---|---|---|
| Use a container from this datastore as the right side (pairwise) or as a source (SQL mode) of a Computed Join |
Reading the joined output afterwards depends only on permission on the join's datastore (Reporter or higher), since the output container lives there.
Ownership Exceptions
- Authors create joins with themselves as the owner. An Author can leave
owner_idblank (the server defaults it to the calling user) or pass their own user id. Only Editors can pass another user's id as the owner. - Authors cannot transfer ownership. Even an Author who currently owns a Computed Join cannot reassign the owner to a different user. Only an Editor on the join's datastore can change
owner_id. - Ownership does not extend to running operations. Scanning, profiling, and materializing the joined output stay on the Editor team permission, so an Author who owns a Computed Join can change its definition but cannot run it.