Skip to main content
Version: Latest

Roles & permissions overview

In NocoDB, we have roles that determine what people can do in a Workspace or Base.

You can give a member one of these roles:

  • Creator
  • Editor
  • Commenter
  • Viewer

Role for a member, if assigned at base level carry precedence over workspace level role.

When inviting a user, their role designation is initially assigned but can be modified later. Our role system operates incrementally, with higher-level roles encompassing all privileges of lower-level roles. This hierarchy offers flexibility in permissions and fosters a transparent organizational structure in workspace or base management.


Roles serve as the basis for user privileges in NocoDB. They are associated with members at two levels: Workspace and Base. When a member is invited to a Workspace with a specific role, like an "Editor," they automatically have that role in all Bases within that Workspace. However, project owners or creators can customize permissions at the project level to align with specific needs. This dual-level role assignment system ensures adaptable user permissions and access management in NocoDB.

Owner: When a member creates a new Workspace or Base, they automatically become the Workspace or Base "Owner." \This role grants exclusive privileges, including the authority to delete the Workspace or Base. The "Owner" role's privileges are non-transferable, ensuring ownership and control integrity.

Creator: The "Creator" role shares all privileges with an "Owner," except for deleting the workspace or base. "Creators" have full administrative rights, except for deletion authority, which remains exclusive to the "Owner." This ensures balanced workspace or base management.

Editor: An "Editor" can create and edit records but cannot modify the project schema, like adding tables or fields. They strike a balance between data input and schema management.

Commenter: The "Commenter" role cannot add or edit records but can provide comments on existing records , facilitating communication and feedback.

Viewer: "Viewers" can only access records and associated comments, without the ability to contribute or make changes, ensuring controlled access for informational purposes.

No Access: This role, applied exclusively at the base level, revokes project access for the designated user, ensuring robust security and access management.

Workspace level permissions

The individual who creates the workspace is automatically designated as a Workspace owner. A workspace can have only one Owner. Access to bases within that workspace is granted to members based on their roles within the parent workspace. When a member becomes part of a workspace, the role at the workspace level is automatically applied to them for all bases in that workspace, unless a specific exception is configured to override at base level.

Invite member to workspace✔️✔️
Manage member access to workspace✔️✔️
Remove member access from workspace✔️✔️
View members in workspace✔️✔️
Delete Workspace✔️
Billing & upgrade options✔️
Create a new base✔️✔️✔️✔️✔️
Access existing bases at assigned roles✔️✔️✔️✔️✔️

Base level permissions


Invite members to base at or below your role✔️✔️
Manage members access to base✔️✔️
Remove member access from a base✔️✔️
View members in a base✔️✔️
Share base✔️✔️
Share view✔️✔️

Table & view operations

Add / modify / delete table✔️✔️
Add / modify / delete fields✔️✔️
Add / modify / delete views✔️✔️
Hide / un-hide / reorder fields✔️✔️✔️✔️✔️
Add / modify / delete sort✔️✔️✔️✔️✔️
Add / modify / delete filters✔️✔️✔️✔️✔️
Add / modify / delete group-by✔️✔️✔️✔️✔️

Record operations

Add / modify / delete record✔️✔️
View & add comment on a record✔️✔️✔️✔️
View record✔️✔️✔️✔️✔️

Automations & advanced

Add / modify / delete Webhook✔️✔️
ERD (Project & Table relations)✔️✔️✔️✔️✔️
API Snippet✔️✔️✔️✔️✔️
API Token✔️✔️✔️✔️✔️