Roles & Permissions

​

Overview

On this page you will learn how access control works in Trickest, what roles exist at each level, and how permissions are inherited through teams. Trickest uses role-based access control (RBAC) to manage what users can access and do within a Vault. Rather than configuring permissions per user per resource, you assign roles. Each role carries a defined set of permissions, and users get everything those roles allow. There are two independent levels of roles:

• Global roles apply across the entire Vault and control organization-wide capabilities, such as inviting users and managing workspaces.
• Workspace roles apply within a specific workspace and control what a user can do with that workspace’s content.

Roles can be assigned directly to individual users or to teams. When a user has multiple roles that apply to the same resource, the most permissive one takes precedence.

​

Global Roles

All users have exactly one global role. It determines what they can do at the Vault level, independent of any workspace.

​

Super Admin

The highest level of access in a Vault. Super Admins have full visibility and control over the entire organization. They are the only users who can invite new users, manage global settings, and administer teams.

​

Workspace Admin

Can create and manage their own workspaces, and view all Vault users and teams. Cannot access workspaces they have not been explicitly added to, and cannot invite users or change global settings.

​

Member

A standard Vault user with no elevated platform-wide permissions. Access to content is determined entirely by the workspace roles they are assigned.

​

Global Role Permission Matrix

​

Workspace Roles

Workspace roles are assigned per workspace. A user can have different roles in different workspaces. Users who create a workspace are automatically assigned the Owner role for it.

​

Owner

Full control over the workspace. Can manage users, variables, workflows, solutions, and runs. The only role that can add or remove users from a workspace.

​

Write

Can build and modify workflows, edit solutions, and manage projects. Cannot manage users or workspace variables.

​

Execute

Can run existing workflows and view their results. Cannot create, edit, or delete anything.

​

Read

Can view workflows, projects, runs, and files. Cannot create, edit, execute, or delete anything.

​

Workspace Role Permission Matrix

​

Teams and Permission Inheritance

A team is a named group of users that can be assigned roles, just like individual users. Teams exist so you can manage access for a group of people in one place rather than configuring each user separately. A user can belong to multiple teams. Their effective permissions are the union of all roles from every team they belong to, plus any roles assigned to them directly. When roles conflict, the most permissive one wins. Example: A user belongs to two teams. Team A has the Execute workspace role on Workspace X, and Team B has the Write workspace role on the same workspace. The user’s effective role on Workspace X is Write.

​

How It Relates

• Workspaces — workspace roles are always scoped to a specific workspace. A user with no workspace role on a given workspace has no access to it. See Workspaces & Projects.
• Users — new users start with no workspace roles. They must be added to a workspace with an explicit role before they can access anything in it.

​

Next Steps