Understanding role hierarchy for access control

Understanding role hierarchy is essential for designing secure, scalable permission structures that balance ease of management with precise access control.

This guide covers how Baserow’s role hierarchy system determines permissions, understand precedence rules when multiple roles conflict, and grasp the principles that govern access control across workspaces, databases, and tables.

Overview

Baserow’s role hierarchy creates a flexible permission system where access is determined by the most specific role assignment, with individual permissions always overriding team-based access.

Rather than a flat permission model, Baserow uses levels of role assignment: workspace, database, and table, allowing administrators to set broad defaults while making targeted exceptions. When a member has multiple roles from different sources, the hierarchy system automatically determines which permission applies.

Example: Sarah has Editor role at workspace level, Viewer role on Finance database, and Admin role on Budget table. Sarah can edit everywhere except the Finance Database (view only), but has admin access specifically to the Budget Table.

Understanding the permission hierarchy

Baserow’s permissions are applied in a “top-down” hierarchy, where more specific settings always override broader ones. This allows you to set general rules at the highest level and then create specific exceptions where needed.

A more specific permission (like at the Table level) will always take precedence over a more general permission (like at the Workspace level).

The hierarchy flows in this order:

No access (no roles assigned)
  ↓ 
Workspace-level team role (least specific)
  ↓ 
Workspace-level individual role (Default baseline for all content)
  ↓ overridden by
Database-level team role
  ↓ 
Database-level individual role (Department or project-level exceptions)
  ↓ overridden by
Table-level team role
  ↓ 
Table-level individual role (Granular, specific restrictions)

This structure is designed to be flexible. You can set generous, team-wide defaults at the Workspace level while securely locking down specific, sensitive data at the Table level.

Role assignment and inheritance principles

  • Workspace role = default – Applies everywhere unless overridden
  • Individual > Team – Member-specific roles take precedence over team roles
  • Specific > General – Table overrides beat database, database beats workspace
  • Highest permission wins – When multiple sources exist, the highest prevails

Learn more about role capabilities.

Hierarchical team access

Higher-level teams can access content owned by lower-level teams, but not vice versa.

Workspace-level individual role is the default baseline. Permissions set here apply to all databases and tables within the workspace unless overridden.

Settings at the database-level individual role level override the Workspace permissions for all tables within that specific database.

Settings at the table-level individual role level override both Database and Workspace permissions, giving you granular control over a single table.

Learn how to implement team hierarchies.

Role hierarchy principles

Principle 1: Specificity wins

The most specific role assignment takes precedence, regardless of permission level. This allows you to lock down sensitive tables even for workspace admins.

Example: A workspace member has Admin role at workspace level, and Viewer role on specific table. The viewer role applies to that table (table is more specific than workspace)

Principle 2: Individual overrides team

Individual member roles ALWAYS override team roles at the same level.

A member’s individual role assignment always takes precedence over roles inherited from team membership. This enables targeted restrictions for specific members within a team.

Example: A workspace member has a Viewer role individually on Database A, and the member’s team has an Admin role on Database A. The workspace member gets the Viewer role (individual assignment wins)

Principle 3: Highest permission across teams

When a member belongs to multiple teams with different roles at the same level, they receive the highest permission. This prevents accidentally limiting access through team memberships.

Example: If a workspace member belongs to Team A (Viewer) and Team B (Editor) on Database X, the member gets the Editor role (higher permission wins)

Principle 4: “No Role” requires explicit access

“No Role” at the workspace level means zero default access; members need team membership or explicit database/table grants to access anything. This creates the least privilege security model, where all access is explicit.

Example: A workspace member has No Role at workspace level, and has Editor on Database A via team. Editor access to Database A only, no access to other databases

How roles are determined

Decision flowchart

When a member tries to access a table, Baserow checks permissions in this order:

1. Does the member have a table-level individual role?
   YES → Use that role ✓
   NO → Continue to step 2

2. Does the member have a table-level role via any team?
   YES → Use the highest team role ✓
   NO → Continue to step 3

3. Does the member have a database-level individual role?
   YES → Use that role ✓
   NO → Continue to step 4

4. Does the member have a database-level role via any team?
   YES → Use the highest team role ✓
   NO → Continue to step 5

5. Does the member have a workspace-level individual role?
   YES → Use that role ✓
   NO → Continue to step 6

6. Does the member have a workspace-level role via any team?
   YES → Use the highest team role ✓
   NO → No access ✗

Frequently asked questions

What happens when I change a workspace-level role?

The change only affects resources where no more specific role exists. Database and table-level overrides remain unchanged.

Can I restrict an Admin’s access to specific tables?

Yes. Assign Admin at workspace level, then set a lower role (or “No access”) at the specific table level. Table-level roles override workspace roles.

How do I troubleshoot unexpected access?

Check permission sources in order: table individual → table team → database individual → database team → workspace individual → workspace team. The first match determines access.

What’s the difference between “No Role” and “No access”?

“No Role” is an explicit assignment meaning “no default access” (but other sources can grant access). “No access” is the result when no permissions exist at all.

Do new databases inherit workspace roles?

Yes. When someone creates a new database, members’ workspace-level roles apply automatically unless you set database-specific overrides.

Can a member have different roles on different tables in the same database?

Yes. Table-level overrides apply independently. You can assign different roles for each table regardless of database-level settings.

Related content

Understand the system:

Implement permissions:

Manage access:

Still need help? If you’re looking for something else, please feel free to make recommendations or ask us questions; we’re ready to assist you.