Field-level permissions

Field-level permissions work alongside Baserow’s role hierarchy (workspace → database → table) as an additional security layer. Members who can access a table may still be restricted from editing certain fields based on their role level.

This guide covers how to control who can edit specific fields within tables, protect sensitive columns like salary or SSN, and implement the most granular permission control available in Baserow.

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

Overview

Field-level permissions let you restrict editing of individual columns within a table—protecting sensitive fields like salary, SSN, or performance ratings while allowing broader table access for other data.

Unlike table-level permissions that control access to entire tables, field-level permissions provide column-by-column control. This is Baserow’s most granular permission layer, operating within table-level access to fine-tune who can modify specific data fields.

When to use field-level permissions

Field-level vs. other permission levels

Permission Level	Granularity	Use When
Workspace roles	All content	Setting org-wide defaults
Database roles	All tables in database	Creating department boundaries
Table roles	All fields in table	Protecting entire tables
Field permissions	Individual columns	Protecting specific columns within accessible tables

Common use cases

Scenario	Implementation	Why Field-Level Works
Salary data	Employee table accessible, Salary field Admin-only	HR needs other employee data, only executives see salary
Social Security Numbers	Customer table editable, SSN field Admin-only	Sales team edits customer info, can’t modify SSN
Performance ratings	Review table accessible, Rating field Builder+	Reviewers enter data, only managers edit final ratings
Audit timestamps	Any table, Created/Modified fields Read-only	Everyone sees when changes happened, no one can alter timestamps
Calculated fields	Financial table, Formula fields Read-only	Team views calculations, formulas protected from accidental changes
Configuration settings	Settings table, API Keys field Admin-only	Developers see other settings, can’t edit production keys

Field-level vs. hiding fields

Feature	Purpose	Visibility	Editing
Field-level permissions	Control who can EDIT	Everyone can see	Restricted by role
Hide fields (view settings)	Control who can SEE	Hidden from view	N/A if hidden

You can use field-level permissions when everyone should see the data, but only specific roles should edit it, and you need an audit trail of who can modify the data.

Hide fields when the data shouldn’t be visible at all, to simplify the interface for certain users, and to create role-specific views.

You can combine both: hide the field in certain views and restrict editing via field permissions.

How field-level permissions work

Permission hierarchy within tables

Field permissions operate as a fourth layer on top of table access:

1. Workspace Role (baseline)
   ↓
2. Database Role (dept/project override)
   ↓
3. Table Role (table access)
   ↓
4. Field Permissions (column editing restrictions)

Field permissions only matter if the member can access the table.

Example: Marketing Team has Editor role on Customers Table. Customer SSN field set to Admin-only editing. Marketing can edit customer data, but cannot edit the SSN field (view only)

Permission levels

Level	Who Can Edit	Common Use Cases
Admins only	Workspace/database/table admins	Ultra-sensitive data: salary, SSN, legal documents
Builders and higher	Builders + Admins	Structural data: formulas, configurations, system settings
Editors and higher	Editors + Builders + Admins	Standard collaborative data (default)
Nobody (Read-only)	No one can edit	Calculated fields, audit timestamps, imported historical data

Interaction with table roles

Field permissions refine table-level access, they don’t replace it:

Table Role	Field Permission	Effective Access
Editor	Editors and higher	✓ Can edit field
Editor	Builders and higher	✗ Can view, cannot edit
Editor	Admins only	✗ Can view, cannot edit
Viewer	Editors and higher	✗ Can view, cannot edit (Viewer can’t edit anything)
Commenter	Editors and higher	✗ Can view, cannot edit (Commenter can’t edit data)
Admin	Admins only	✓ Can edit field

Field permissions can only restrict editing further; they can’t grant editing to roles that can’t edit the table.

Set field-level permissions

1. Navigate to your table to access field permission settings
2. Locate the field you want to protect
3. Click the dropdown arrow next to the field name in the header
4. Select Field options
5. Click the Permissions tab to configure the permission level and choose the appropriate restriction:
6. Click Save to apply the permission
7. Icon appears next to the field name, indicating restricted editing
8. Test with different role accounts to verify behavior

Users see a lock icon or visual indicator on fields they cannot edit, making permissions transparent.

Advanced field permission strategies

Strategy 1: Progressive data refinement workflow

Data moves through approval stages with increasing restrictions. Content publishing workflow, Clear workflow with each stage protected appropriately.

Implementation:

1. Draft field: Editors and higher (team creates content)
2. Review Notes field: Builders and higher (managers review)
3. Approved field: Admins only (executives approve)
4. Published Date field: Read-only (system-generated, no edits)

Strategy 2: Sensitive columns in shared tables

Share most data, protect specific sensitive columns. Employee directory with sensitive info, Company directory accessible to all, sensitive fields locked down.

Implementation:

• Table access: All staff → Viewer on Employees table
• Name, Email, Department fields: Editors and higher (HR updates)
• Salary field: Admins only (CFO access)
• SSN field: Admins only (HR Director only)
• Performance Rating field: Builders and higher (Managers)

Strategy 3: Configuration tables with secrets

Developers see settings, can’t modify production secrets. Application configuration database, Developers work with configs safely, production secrets protected.

Implementation:

• Table access: Dev Team → Editor on Config table
• Environment field: Editors and higher (dev/staging/prod indicator)
• API Endpoint field: Builders and higher (senior devs config)
• API Secret Key field: Admins only (DevOps lead only)
• Last Modified field: Read-only (audit trail)

Strategy 4: Audit-compliant data entry

Meet compliance requirements for financial data. Financial transactions table, Clear audit trail with tamper-proof timestamps.

Implementation:

• Table access: Finance Team → Editor
• Transaction Amount field: Editors and higher (team enters)
• Approved By field: Builders and higher (managers approve)
• Audit Status field: Admins only (auditors mark reviewed)
• Created On, Modified On fields: Read-only (tamper-proof)

Strategy 5: Client data with PII protection

GDPR/HIPAA compliance for personal data. Customer relationship management, Compliance-ready customer data management

Implementation:

• Table access: Sales Team → Editor on Customers table
• Name, Company, Email fields: Editors and higher
• Phone Number field: Builders and higher (managers verify)
• SSN, Tax ID fields: Admins only (legal team only)
• Medical Notes field: Admins only (healthcare team only)
• Consent Date field: Read-only (legal requirement)

Field permissions in forms

When using Baserow forms, field-level permissions affect which fields can be set during form submission:

• Fields with Editors and higher: ✓ Can be included in forms
• Fields with Builders and higher: ✗ Cannot be set via form submission
• Fields with Admins only: ✗ Cannot be set via form submission
• Fields with Read-only: ✗ Cannot be set via form submission

Use case: Public form for lead generation where form submitters can fill basic info, but internal ratings/scores can only be added by staff after review.

To configure form submission restrictions:

1. Set field permission level in table settings
2. The field automatically becomes unavailable in the form designer for restricted permissions
3. Form submitters can only fill fields they have permission to edit

Learn more about creating forms.

Field permissions and API access

API respects field permissions

Field-level permissions apply to both web interface and API requests. API reads always return field data (if table access exists), API writes respect field permission levels. Attempting to edit a restricted field via API returns a permission error.

Example API response:

{
  "error": "ERROR_FIELD_NOT_EDITABLE",
  "detail": "User does not have permission to edit this field"
}

Best practice: Test API integrations with different role accounts to ensure field permissions work as expected.

Learn more about Baserow API.

Troubleshooting field permissions

“Users can’t edit expected fields”

It is possibly because the field permission is too restrictive for the user’s role, the user’s table role doesn’t allow editing (Viewer, Commenter), or workspace/database role overrides are causing confusion

Check field permission setting (Field Options → Permissions), verify user’s role at the table level (must be Editor or higher to edit any field), and confirm user’s effective role considering workspace → database → table hierarchy

“Field permission changes not applying”

This is because browser cache or session issue. Refresh the page (hard refresh: Cmd/Ctrl + Shift + R), clear browser cache, log out and log back in, and try a different browser to isolate the issue

“Admin can’t edit field despite Admin role”

This is because the field is set to “Read-only” (Nobody). “Read-only” fields cannot be manually edited by anyone, including admins. This is intentional for calculated fields, formulas, and system-generated data. Change the field permission to “Admins only” if manual editing should be allowed for admins.

“Permissions working in web but not in API”

API should respect field permissions. Verify API token has correct permissions, check if using database token vs. user token, and contact support if API permissions aren’t matching web behavior

Frequently asked questions

Can I set different view permissions and edit permissions for the same field?

Yes. You can hide a field in specific views (view-level setting) while still restricting who can edit it via field-level permissions. These are independent settings that work together.

Do field-level permissions affect calculated fields and formulas?

Read-only permission is automatically applied to formula fields since they can’t be manually edited. You can also set formula fields to other permission levels if you want to control who can modify the formula itself.

Can I bulk-edit field permissions across multiple fields?

No. Field permissions must be set individually for each field. This ensures intentional, careful permission assignment for sensitive data.

What happens to existing data when I change field permissions?

Data remains unchanged. Field permissions only affect future editing capabilities—they don’t modify, hide, or delete existing field values.

Can I see who last edited a restricted field?

Yes, if you have row change history enabled. Row change history tracks all edits, including which user modified which fields. Learn more about row change history.

Do field permissions work with linked records?

Yes. If a field links to another table (Link to table field), field permissions control whether users can modify which records are linked. The permissions on the linked table determine access to the actual linked records.

Can external form submitters edit restricted fields?

No. Form submissions respect field-level permissions. Restricted fields cannot be set via form submission, only by users with appropriate roles editing directly in the table.

Related content

Permission system:

• Understanding role hierarchy
• Role capabilities reference
• Assign roles at table level

Field management:

• Field configuration options
• Hide and show fields
• Formula field overview

Data security:

• Row change history
• Audit logs
• Permissions overview

Forms and API:

• Creating forms in Baserow
• Database API documentation

---

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.

• Ask the Baserow community
• Contact support for questions about Baserow or help with your account