Permissions overview

Codatum has role-based permission management. Every user always has exactly one workspace role. Resources such as connections and teamspaces can also have resource roles, and notebooks and reports can have sharing settings. Whether an operation is allowed is determined by a combination of these.

You manage the organization name, country, organization owners, billing address, payment method, and invoices in Organization settings. You change the plan in workspace settings > Plans. Whether those operations are allowed is determined by whether you are an organization owner, not by your workspace role.

Terminology

Terms used to describe permissions. For more detailed definitions, such as the relationship between accounts and users, also see Account and the Glossary.

Term	Meaning
User	An account that belongs to a workspace
Group	A collection of users that can be granted permissions together. A single group can be assigned multiple resource roles
Resource	An object such as a notebook, connection, or teamspace
Operation	An action such as inviting a user or editing a notebook
Workspace role	A role assigned to a user within a workspace
Resource role	A role tied to an individual resource, assigned to a group or an individual user
Permission	The ability to perform a specific operation, determined by a combination of roles

Evaluation rules

1. Roles have a hierarchy. A lower role's access is also carried by higher roles (Role hierarchy).
2. The workspace role sets the default range, and resource roles widen it for individual resources. Operations the workspace role allows can be performed without a resource role. Operations it doesn't allow can still be performed when a resource role on that resource allows them.
3. Workspace Viewer and Workspace Guest act as an upper limit. Even with a resource role, operations these roles can't perform, such as editing, aren't allowed. Workspace Owner, Workspace Editor, and custom roles have no upper limit.
4. Multiple roles on the same resource are evaluated with OR. If any one of them allows the operation, whether granted directly or through a group, it's allowed.
5. Operations tied only to the workspace are determined by the workspace role alone. For example, inviting users.

Conditions such as "Workspace Editor or higher, and ..." on each resource's permissions page describe how built-in roles are evaluated. For custom roles, the permissions you choose determine the result.

For operations determined by the workspace role alone, see Workspace permissions.

Role hierarchy

"X or higher" in the tables means that role and any higher role can perform the operation.

Type	From highest to lowest
Workspace role	Workspace Owner, Workspace Editor, Workspace Viewer, Workspace Guest. Custom roles aren't part of this hierarchy. Because you choose permissions for each area, a custom role can't be ranked against the built-in roles in a single hierarchy. What it can do is determined by the permissions you choose.
Connection resource role	Connection Owner, Connection User, Connection Viewer
Teamspace resource role	Teamspace Owner / Teamspace Editor / Teamspace Viewer (Owner and Editor/Viewer aren't mutually exclusive. For details, see Teamspace permissions)

Main topics

• Workspace permissions
• Group / Connection / Teamspace
• Notebook / Report
• Workflow
• Saved query / Catalog
• AI agent permissions

Control methods

How permissions are determined varies by resource.

Method	Target	What determines it
Resource role	Group	Group Owner (resource role)
Resource role	Connection	Access level and the granted resource role
Resource role	Teamspace	The granted resource role
Resource sharing settings	Notebook / Report	The access scope of the root folder, and additional notebook permissions or report sharing settings
Owner assignment	Workflow	The owners (users or groups) assigned to each workflow. Creation and managing all workflows are governed by the workspace role
Derived	Saved query / Catalog	The permissions of the linked connection. There's no dedicated resource role
Follows the executing user's permissions	AI agent	No dedicated resource role. Additional restrictions come from the AI profile's tool permissions. Agent connectors also require being listed in Admins and users

Access scope

For some resources, such as notebooks, the type of root folder they belong to becomes the access scope, which determines how permissions are evaluated. For the conditions for each operation, see Notebook access scope.

Scope	Key points
Workspace	Workspace members can access it according to their workspace role
Teamspace	Access is determined by the teamspace resource role
Private	Under the "Private" root folder. Only the owner, if they're a Workspace Editor or higher, can operate on it
Shared	Users and groups granted permissions through additional notebook permissions can access it. It appears in the Shared folder on the recipient's side

Relationship with credentials

Credential	How permissions apply
Browser login (account)	Evaluated by the workspace role / resource role of the user in their workspace
PAT	Capped by the permissions of the token's account, and further narrowed by the permission boundary (connections / notebooks / tags) specified at issuance. A user's PAT is capped by the permissions of the user who issued it, and a service account's PAT by the service account's permissions. See Personal Access Tokens for issuance, and Personal Access Tokens for managing them within a workspace
Switching to a service account	Evaluated by the service account's workspace role / groups / resource roles, not those of the user who switched. See Service account permissions for details
API key	Tied to the workspace. Only usable for granted signed embeds. See API keys for details