Role Based Permission Levels

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.

Hierarchy of roles

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.

  • Member roles take priority over Team roles. A group member who is explicitly assigned a role on a group, database or table will get that exact role, regardless of the default roles of the teams to which they belong.
  • Database roles will override Group roles. A role assigned to a team or a user on a Database will override that team or user’s default Group role.
  • Table roles will override Group and Database roles. A role assigned to a team or a user on a Table will override that team or user’s database or group role.

Permission levels

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.

Group level roles

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.

Database level roles

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

Table level roles

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.

Troubleshooting

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:

  1. Invite everyone to your Group with “No Role” by default.
  2. Invite users to teams
  3. 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!