You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In NocoDB, roles define what users or teams can do within a **Workspace** or a **Base**.
10
+
They govern access control, ensuring that members and teams have appropriate privileges based on their responsibilities.
9
11
10
-
In NocoDB, we have roles that determine what people can do in a Workspace or Base.
12
+
<Callouttype="info">Teams feature availability: **Business** plan onwards in cloud and On-premise **Enterprise** edition</Callout>
11
13
12
-
You can give a member one of these roles:
14
+
You can assign the following roles:
13
15
* Owner
14
-
* Creator
16
+
* Creator
15
17
* Editor
16
-
* Commenter
18
+
* Commenter
17
19
* Viewer
18
20
* No Access
19
21
20
-
<Callouttype="info">
21
-
If a role is assigned to a member at the base level, it takes precedence over a role assigned at the workspace level.
22
-
</Callout>
22
+
& a special role "Inherit" discussed below.
23
+
24
+
If a role is assigned at the base level, it takes precedence over the workspace-level role. Roles are hierarchical — higher roles include all permissions of the roles below them, allowing flexibility and clarity in managing access across your workspace and bases. Details about each role and their permissions are provided below.
23
25
24
-
When inviting a user, their role designation is initially assigned but can be modified later. Our role system
25
-
operates incrementally, with higher-level roles encompassing all privileges of lower-level roles.
26
-
This hierarchy offers flexibility in permissions and fosters a transparent organizational structure
27
-
in workspace or base management.
28
26
29
27
## Roles
30
-
Roles serve as the basis for user privileges in NocoDB. They are associated with members at two levels:
31
-
Workspace and Base. When a member is invited to a Workspace with a specific role, like an "Editor," they
32
-
automatically have that role in all Bases within that Workspace. However, base owners or creators can customize
33
-
permissions at the base level to align with specific needs. This dual-level role assignment system
34
-
ensures adaptable user permissions and access management in NocoDB.
28
+
Roles define access privileges in NocoDB and can be assigned at two levels — **Workspace** and **Base**.
29
+
30
+
When a member or team is invited to a workspace with a specific role (for example, **Editor**), they automatically receive that level of access across all bases within the workspace, unless overridden at the base level.
31
+
Base owners or creators can further refine permissions at the base level to meet specific collaboration needs.
32
+
33
+
This dual-level role structure provides granular control, balancing workspace-wide consistency with base-specific customization.
34
+
35
+
Workspace-level roles do not automatically grant access to **Private Bases**. Members must be explicitly invited to a Private Base to gain access, regardless of their workspace role. Learn more about Priavte Bases in the [Private Bases documentation](/docs/product-docs/bases/private-base).
36
+
37
+
The following sections detail each role and its associated permissions.
38
+
39
+
### **Owner**
40
+
- Assigned automatically to the person who creates a workspace or base.
41
+
- Has full administrative privileges, including the ability to delete the workspace or base.
42
+
- Only **individual members** can be assigned the Owner role. **Teams** cannot be assigned this role.
43
+
44
+
### **Creator**
45
+
- Has full control over the workspace or base except for deletion privileges, which are exclusive to the Owner.
46
+
- Can manage users, schema, automations, and all data operations.
47
+
- Suitable for administrators and key project leads.
48
+
49
+
### **Editor**
50
+
- Can add, edit, and delete records within tables.
51
+
- Cannot modify the schema, such as adding or removing tables, fields, or relationships.
52
+
- Has access to toolbar features like **Filter**, **Sort**, and **Group By** for managing data views.
53
+
- Ideal for contributors responsible for day-to-day data management.
54
+
55
+
### **Commenter**
56
+
- Can view records and leave comments on existing entries.
57
+
- Cannot edit, delete, or add records.
58
+
-**Toolbar access** (Filter, Sort, Group By) is not available.
59
+
- Best suited for reviewers or collaborators providing feedback.
60
+
61
+
### **Viewer**
62
+
- Has read-only access to records and comments.
63
+
- Cannot make any data changes or leave comments.
64
+
-**Toolbar access** (Filter, Sort, Group By) is not available.
65
+
- Ideal for external stakeholders who need view-only access.
66
+
67
+
### **No Access**
68
+
- Revokes access entirely to a workspace or base.
69
+
- When applied at the workspace level, the user or team cannot access any bases within it.
70
+
- When applied at the base level, it restricts access to that base only.
71
+
72
+
### **Inherit**
73
+
"Inherit" is a special role that allows users to derive their permissions based on team assignments within a workspace. It functions as follows:
74
+
75
+
- At the **workspace** level, allows users to derive their role from team assignments within the workspace.
76
+
- At the **base** level, adopts the role defined at the workspace level.
77
+
- Offers flexibility in managing roles across multiple bases within a workspace.
78
+
- Note: The Inherit role cannot be directly assigned at the workspace level.
79
+
80
+
If a user is invited to a workspace with the **Inherit** role and then added to a team with the **Viewer** role, the user will have **Viewer** access across all bases within that workspace.
81
+
If the user is invited to the workspace with the **No Access** role and later added to a team with the **Editor** role, the user will still have **No Access** in all bases within that workspace.
82
+
83
+
The **Inherit** role is the only explicit role that allows role derivation from team assignments. For all other roles, explicit workspace roles take precedence over corresponding team roles.
84
+
85
+
At base level, if a user is assigned the **Inherit** role, their effective role will be determined by their workspace-level role or team-derived role, following the effective role resolution rules outlined below.
35
86
36
-
**Owner**: When a member creates a new Workspace or Base, they automatically become the Workspace or Base "Owner."
37
-
This role grants exclusive privileges, including the authority to delete the Workspace or Base.
38
87
39
-
**Creator**: The "Creator" role shares all privileges with an "Owner," except for deleting the workspace or base.
40
-
"Creators" have full administrative rights, except for deletion authority, which remains exclusive to the "Owner."
41
-
This ensures balanced workspace or base management.
88
+
## Effective Role Resolution
42
89
43
-
**Editor**: An "Editor" can create and edit records but cannot modify the base schema,
44
-
like adding tables or fields. They strike a balance between data input and schema management.
90
+
Effective permissions for a user at base level are determined by combining explicit (individual) assignments and team-derived assignments using the following precedence rules:
45
91
46
-
**Commenter**: The "Commenter" role cannot add or edit records but can provide comments on existing records
47
-
, facilitating communication and feedback.
92
+
1. Explicit individual role at Base (highest precedence)
93
+
2. Best (most permissive) role among Team roles assigned at Base
94
+
3. Explicit individual role at Workspace level other than "Inherit"
95
+
4. Best (most permissive) role among Team roles assigned at Workspace
96
+
5. No-access (default)
48
97
49
-
**Viewer**: "Viewers" can only access records and associated comments, without the ability to contribute
50
-
or make changes, ensuring controlled access for informational purposes.
98
+
**Notes**
99
+
- An explicit individual assignment always overrides any team-derived role at the same level.
100
+
- Lower-level roles (Base) override higher-level roles (Workspace) when an explicit assignment exists at the lower level.
101
+
- When multiple team roles apply, the system chooses the most permissive role (for example, between Viewer and Editor it will choose Editor).
51
102
52
-
**No Access**: This role, applied at the base level, revokes base access for the designated user. When applied at the workspace level, it gives the user no default access to any base within the workspace.
103
+
**Base hierarchy**:
53
104
105
+
`Individual Base role` > `Team Base role` > `Individual Workspace role` > `Team Workspace role` > `No Access`
When a user belongs to multiple teams, their Team role is determined by the highest (most permissive) role among all their team assignments.
112
+
113
+
## Roles for Teams
114
+
Teams function as a collective access unit for easier management. When a team is assigned a workspace or base role:
115
+
- All team members inherit that role automatically.
116
+
- Individual user roles can override team-assigned roles if explicitly set.
117
+
- A team can be invited at both workspace and base levels for broader or limited access.
118
+
- Teams **cannot** be assigned the **Owner** role.
119
+
- Teams **cannot** be assigned the **Inherit** role at the workspace level.
120
+
121
+
<Callouttype="info">If a team is invited at the workspace level, all its members receive that workspace role unless an individual or base-level role provides different access.</Callout>
0 commit comments