Baserow Role Based Permissions give organizations more flexibility around permissions that can be granted to users. Role Based Access Control allows admins to provide users with varying levels of access based on their roles.
This support article describes the various actions available to users at each role level.
Assigning role based permission is only available to users with a Self-hosted Enterprise License or on SaaS Hosted Advanced Plan on Baserow.io.
The right role determines what actions users can or cannot take in the Groups, Databases, and Tables to which they have access. You can assign members one of the following roles – Admin, Builder, Editor, Commenter, Viewer, No Access or No Role. For an overview of each role, please refer to this support article.
Roles are hierarchical, which means that a higher role can perform all of the functions of a lower role. You can lower or raise the role of a user or team by assigning a role on a specific table or database.
When a user has varying roles across group, database and table levels, we pick the most specific roles first and ignore any database or group level roles.
Roles can be assigned to members or teams at three levels: Group, Database, and Table. The levels define how different users access data in a Group, Database or Table.
When a member is added to a group, a default role is initially set. The member will have access to the entire group at the role level assigned to them. Learn how to assign a default role for a group.
The person who created the group is automatically designated as an admin. There may be more than one admin for a group.
Teams or members may gain access to databases and tables in that group, through their roles in the parent group. If a team or member joins a group, the default role at group level is automatically assigned to them on all databases and tables in the group, unless an exception is set and a role with a higher hierarchy takes precedence.
Admin | Builder | Editor | Commenter | Viewer | |
---|---|---|---|---|---|
General actions | |||||
Invite members into the group | ✓ | ||||
Manage roles of members of the group | ✓ | ||||
Remove access from all other users | ✓ | ||||
View the trash for database or group | ✓ | ✓ | |||
Access/view the group, database and table within the group at your assigned role | ✓ | ✓ | ✓ | ✓ | ✓ |
The power to invite a member into the group and manage existing users is restricted to the Admins of that Group. Admins on a Database or Table can only manage the roles for that Database or Table, not the entire Group.
If a user or team has a role in a Database, they automatically get that role on every table in that database. They will only have access to tables in that specific database at the role level that you have assigned to them, unless an exception is set and a role with a higher hierarchy takes precedence.
Learn how to assign roles on individual databases.
Admin | Builder | Editor | Commenter | Viewer | |
---|---|---|---|---|---|
General actions | |||||
Invite users to Database at or below your role | ✓ | ||||
Manage roles of members on that Database | ✓ | ||||
Remove access from all other users * | ✓ | ||||
View the trash for database | ✓ | ✓ | |||
Access/view the database and tables within the group at your assigned role | ✓ | ✓ | ✓ | ✓ | ✓ |
Create, delete, rename and re-order databases |
If a user or team has a default role in a Table, they will only have access to that table at the role level to which they have been assigned. They automatically get that role on the specific table, unless an exception is set and a role with a higher hierarchy takes precedence.
Learn how to assign roles on individual tables.
Admin | Builder | Editor | Commenter | Viewer | |
---|---|---|---|---|---|
General actions | |||||
Manage roles of members of that Table | ✓ | ||||
Remove access from all other users * | ✓ | ||||
Access/view the specific table at your assigned role | ✓ | ✓ | ✓ | ✓ | ✓ |
Field actions | |||||
Create and delete fields, update them (fields or meta data of the table), rename them and re-order them | ✓ | ✓ | |||
View actions | |||||
Make views, webhooks and generate links to share the view publicly | ✓ | ✓ | |||
Row and Cell actions | |||||
Update cells in a table | ✓ | ✓ | ✓ | ||
Update, create and delete rows | ✓ | ✓ | ✓ | ||
Leave comments on every row | ✓ | ✓ | ✓ | ✓ | |
View the data in a table | ✓ | ✓ | ✓ | ✓ | ✓ |
Admins in a Group, Database or Table can remove access from each other. For example, an admin can make a database and assign the “No Access” role to all other users to make it private.
For a full technical list of what each role can do, view our internal database. The operations each role can do is stored in the database.
What is an ideal best practice to fully utilize role based permissions?
A higher role has all of the permissions of the lower roles. Other users might inherit access to a Database or Table via their respective roles on the parent Database or Group. For ease of use, we recommend the following general workflow:
- Invite everyone to your Group with “No Role” by default.
- Invite users to teams
- Then assign roles on specific tables and databases to teams.
How is a user’s role decided?
When a user is in teams and has roles assigned to a group, but also on individual databases or tables, the following rules apply to decide which role to go with:
- A role assigned to a user or team on a specific table always overrides a role on its database or group
- A role assigned to a user or team on a specific database always overrides a role on its group
- User roles will always override team roles on that same thing. That is, a user who has both an individual role on a table and also is a member of a team with a role on that table, the user’s individual role will always be picked.
For example, if a user has the following individual user permissions: Admin role at the group level, Builder role in database A, and Viewer role in table A. Also, the user is a member of a team with the following team permissions: Viewer role at the group level and Admin role on table A. This user’s active role for accessing table A is as a Viewer - the individual user role assigned to table A - which means they can only view the rows in the table and make no edits.
Learn more about Baserow pricing and who is considered a “user” for billing purposes.
Why give access to users at the database level instead of at the group level?
Group members have access to all databases in the group and can view the contents of the databases. Inviting members to individual databases is a good way to prevent them from accessing sensitive or confidential information.
For example, if there are two teams in a group: Sales Team A and Audit Team. While it is a good idea to have two separate databases for each team in a single group, it may not be a good idea for each team to be able to access each other’s databases. [Create a team and grant appropriate access to the team[(/user-docs/assign-roles-to-teams-at-group-level), or assign key roles to members at the database level rather than at the group level.
There are no admins in a database and table, how can this be resolved?
Databases and Tables can be orphaned if an admin creates a database and then removes access to that database from everyone else in the group. The admin leaves the group. Thus, no users can access the database and its table anymore.
This is reversible by inviting a new user as an admin that hasn’t yet been excluded from the database and having that user grant access to the rest of the group.
If you’re looking for something else, please feel free to make recommendations or ask us questions in our online community—we’re ready to assist you!