Table level permissions

Table-level roles override both workspace and database assignments. This makes them ideal for compliance requirements, protecting confidential data, and creating exceptions for individual tables that need tighter security than their parent database.

This guide covers how to assign roles at the table level for granular access control, protect sensitive tables like payroll or personal data, and override database and workspace permissions for maximum security.

Paid feature: Role-based permissions are available on Baserow Advanced and Enterprise plans. View pricing details.

Overview

Table-level roles provide granular permission control in Baserow, letting you restrict access to specific sensitive tables, like salary data, client contracts, or personal information; even when members have broader access to the database or workspace.

Use table-level permissions when workspace and database roles are too broad for your security needs.

When to use table-level roles

Prerequisites: Members must first be invited to the workspace before you can assign table-level roles. You cannot invite members directly to a table.

Use workspace-level roles when:

  • Members need consistent access across everything
  • Simple, trust-based environment
  • Small team with similar responsibilities

Use database-level roles when:

  • Creating department or project boundaries
  • Different teams need different database access
  • Mid-level granularity is sufficient

Use table-level roles when:

  • Specific tables contain sensitive data within otherwise open databases
  • Compliance requires field-level restrictions
  • Need to restrict access from higher-level admins
  • Individual tables require unique protection
  • Maximum security precision needed

Learn more about role hierarchy.

How table roles work

Table-level roles have high priority in Baserow’s permission hierarchy. Table-level “No Access” role can block even workspace Admins from accessing table data. This is to protect ultra-sensitive data.

Example: A workspace Admin can access everything by default. Salary Table has “No Access” for the workspace admin at the table level. The workspace admin cannot access the Salary Table despite being a workspace Admin.

Inherited vs. explicit access

The table members list shows only explicit table-level assignments, not inherited access. Always check the workspace and database roles when troubleshooting table access.

This means a workspace Editor can edit all tables, but won’t appear in individual table member lists unless you assign a table-specific role. The table member list shows only exceptions to database/workspace defaults. This matters because you might think a table has limited access, but workspace/database roles still grant access.

To truly restrict, assign “No Access” at the table level to override inherited permissions and lock down sensitive tables from members who have Editor or Admin access at the workspace/database level.

How to assign table roles

Grant table access to members or teams

To assign roles at the table level,

  1. Navigate to the table you want to manage

  2. Click the three-dot menu (⋮) next to the table name in the sidebar

  3. Select Manage members from the dropdown

    Manage members option

  4. In the Manage Members modal, click Select Members

  5. Search and select members and/or teams using individual checkboxes, Select all button for bulk selection. The modal shows the total members selected

  6. Choose the role from the dropdown:

  7. Click Invite members/teams (button shows total selected)

The role applies immediately to this specific table only.

View and modify table access

View current table members

The Manage Members modal displays all members and teams with explicit table-level role assignments.

This list shows only explicit table assignments. Members with workspace or database-level access may still access this table, but it won’t appear here unless they have a table-specific role.

To see all effective table access:

  1. Check workspace-level roles (Members page)
  2. Check database-level roles (Manage Members on database)
  3. Check table-level exceptions (Manage Members on table)

The combination determines final access.

Table members view

Change existing roles

  1. Open the table’s Manage members modal
  2. Locate the member or team to modify
  3. Click the role dropdown next to their name
  4. Select the new role

Changes apply immediately to this table only.

Remove table access

To revoke table-level access:

  1. Open Manage members on the table
  2. Select Remove from the role dropdown for that member/team

The workspace member loses the table-level override and falls back to the database-level role (if any). If no database role, they fall back to the workspace role. If no roles at any level, they lose all table access.

Removing table-level access cannot be undone directly; you must re-assign the role.

Table-level permission strategies

Strategy 1: Sensitive tables in open databases

Most tables are accessible, but some tables are locked down. If a database contains salary information, workspace members with access can manage most data, but certain data have special restrictions.

Implementation:

  1. Database level: HR Team → Editor on HR Database
  2. Table level:
    • Salary Table: CFO → Admin, HR Team → Viewer
    • Performance Reviews Table: HR Managers → Editor, HR Staff → Viewer
    • All other tables: inherited Editor from database

Strategy 2: Compliance-required restrictions

A customer database containing personally identifiable information needs strict PII protection to meet GDPR/HIPAA requirements while maintaining operational access.

Implementation:

  1. Workspace level: Customer Success Team → Editor
  2. Database level: Customer Database → inherited Editor
  3. Table level:
    • Customer SSN Table: No Access for all except Compliance Officer → Admin
    • Customer Medical Table: No Access for all except Healthcare Team → Editor
    • Customer Addresses Table: CS Team → Viewer (can see, not edit)

Strategy 3: Prevent admin access to ultra-sensitive data

Confidential information receives ultimate protection; even workspace admins can’t access these tables.

Implementation:

  1. Workspace level: Most users → various roles, including some Admins
  2. Database level: Company Database → various roles
  3. Table level:
    • Board Minutes Table: All workspace Admins → No Access, Board Members → Admin
    • Executive Compensation Table: All except CFO and CEO → No Access

Strategy 4: Audit trail protection

A financial audit requires a compliance-ready audit trail that can only be modified by auditors.

Implementation:

  1. Database level: Finance Database → Finance Team → Editor
  2. Table level:
    • Audit Log Table: All users → Viewer (read-only), System Admin → No Access (cannot edit even as admin)
    • Transaction History Table: Finance Team → Viewer, Auditors → Admin

Strategy 5: Development secrets protection

Configure the database with production secrets to protect API keys and credentials. Developers can work freely, but can’t access or expose production secrets.

Implementation:

  1. Database level: Settings Database → Development Team → Editor
  2. Table level:
    • API Keys Table: No Access for all except DevOps Lead → Admin
    • Production Config Table: Developers → Viewer, DevOps → Editor
    • Test Config Table: inherited Editor from database

Troubleshooting table access

“Why can this member access the table when they’re not in the list?”

This is because they have workspace or database-level access that isn’t overridden at the table level. Check workspace and database roles. To restrict, assign “No Access” at the table level.

“I set ‘No Access’, but the member can still see the table”

This is because a workspace member may have a more specific role at the same table level (individual overrides team). Check if the member has an individual table-level role that overrides the team “No Access” assignment.

“Table Admin can’t invite workspace members”

Table Admins can only manage table access, not workspace or database membership. Only workspace Admins can invite members to the workspace. Have a workspace Admin invite a member first, then the table Admin can assign table access.

“Workspace Admin can’t access table despite being Admin”

This is because the table has explicit “No Access” for that admin at the table level. Table-level “No Access” overrides the workspace Admin role. This is intentional for ultra-sensitive data. If access is needed, have another table Admin modify the table-level permissions.

“Removed someone from a table, but they can still access it”

This is because they have inherited access from workspace or database roles. Removing table-level roles means they fall back to database/workspace roles. To block access, assign “No Access” at the table level instead of removing the assignment.

Frequently asked questions

Can table roles override workspace Admin access?

Yes. Assigning “No Access” at the table level blocks even workspace Admins. This is a powerful way to protect ultra-sensitive data.

Can I assign table roles to members not in the workspace?

No. Members must first be invited to the workspace before you can assign table-level roles. Workspace membership is always required.

What’s the difference between removing table assignment and “No Access”?

  • Remove assignment: Member falls back to database/workspace role (might still have access)
  • “No Access”: Explicitly blocks access regardless of database/workspace roles. Use “No Access” when you need to override inherited permissions.

If I change someone’s database role, does it affect their table roles?

No. Explicit table-level roles always override database and workspace roles. Changing the database role only affects tables where no table-level override exists.

How do I audit who has access to a sensitive table?

Check three places:

  1. Table’s Manage Members (explicit table assignments)
  2. Database’s Manage Members (might grant inherited access)
  3. Workspace Members page (might grant inherited access)

Use audit logs for tracking permission changes.

Related content

Assign roles at other levels:

Understand the system:

Manage access:

Compliance and security:

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.