Field level permissions in a table

Field-level permissions let you control who can edit specific database fields. Set different access levels for editors, builders, and admins, or completely lock fields from modifications. This Advanced plan feature gives you granular control over data security and workflow management.
Baserow’s field-level permissions make it easy to secure sensitive data and control workflows without restricting entire table access.
Overview
Field-level permissions in Baserow allow you to control who can view and edit specific fields within your tables. Unlike table-level permissions that control access to entire tables, field-level permissions provide granular control over individual data columns.
Field level permissions provide granular control over who can edit specific fields in your tables. This enterprise-grade feature is part of our Role-Based Access Control (RBAC) system and is available for Advanced and Enterprise users.

Key benefits
- Data security: Protect sensitive fields from unauthorized edits
- Workflow control: Ensure only qualified team members can modify critical data
- Compliance: Meet regulatory requirements for data access control
- Collaboration: Enable team collaboration while maintaining data integrity
Plan requirements
Field-level permissions are available with Baserow’s Advanced plan and higher. To access this feature:
- Navigate to your workspace settings
- Click on “Subscription”
- Choose the Advanced plan or higher
- Complete the upgrade process
View pricing plans →
Permission Levels
You can set the following permission levels for each field:
Permission Level |
Description |
Admins only |
Field editing restricted to workspace administrators |
Builders and higher |
Field editing available to builders and administrators |
Editors and higher |
Default setting - allows editors, builders, and administrators to edit |
Nobody |
Field becomes read-only for all users |
Admin only permissions
- Use case: Highly sensitive data like employee salaries, confidential ratings
- Access: Only workspace administrators can modify field values
- Visibility: All users can still view the data (unless combined with view-level permissions)
Builder+ permissions
- Use case: Important business data that requires technical oversight
- Access: Database builders and admins can edit
- Common fields: Configuration settings, lookup formulas, calculated fields
Editor+ permissions
- Use case: Standard collaborative data entry
- Access: All team members with edit access can modify
- Common fields: Regular text fields, dates, basic information
Read-only permissions
- Use case: Calculated fields, system-generated data, archived information
- Access: No manual editing allowed
- Examples: Auto-generated timestamps, formula results, imported historical data
How to set field-level permissions
Step 1: Access field settings
- Navigate to your table in Baserow
- Right-click on the field header you want to configure
- Select “Field options” from the context menu
- Click on “Permissions” tab
Choose from these permission levels:
Permission Level |
Description |
Who Can Edit |
Admin only |
Only workspace admins can edit |
Admins |
Builder+ |
Builders and admins can edit |
Builders, Admins |
Editor+ |
Editors, builders, and admins can edit |
Editors, Builders, Admins |
Read-only |
No one can edit the field values |
No one |
Step 3: Apply changes
- Select your desired permission level
- Click “Save” to apply the changes
- The field will now reflect the new permission settings
When using forms, you can further restrict field access by disabling the toggle to prevent this field from being set in rows created through forms.
Best practices
Security considerations
- Audit regularly: Review field permissions quarterly to ensure they match current team needs
- Principle of least privilege: Grant the minimum access level required for each role
- Document permissions: Keep a record of which fields have restricted access and why
Workflow optimization
- Progressive permissions: Start with restrictive permissions and gradually open access as needed
- Role-based design: Align field permissions with your organization’s role hierarchy
- Test permissions: Verify permissions work as expected before rolling out to your team
Troubleshooting common issues
Users can’t edit expected fields
- Check if field-level permissions are set too restrictively
- Verify the user’s role in the workspace
- Ensure table-level permissions allow editing
Permissions not applying correctly
- Refresh the page to ensure changes have loaded
- Check for conflicting table or view-level permissions
- Contact support if issues persist
Frequently asked questions
Can I set different view permissions and edit permissions for the same field?
Yes, you can combine field-level permissions with view-level permissions. For example, you might hide a field from certain views while allowing authorized users to edit it in other views.
Do field-level permissions affect API access?
Yes, field-level permissions apply to both the web interface and API requests. Users accessing data via API will respect the same permission levels as in the web interface.
Can I bulk-edit field permissions across multiple fields?
Currently, field permissions must be set individually for each field.
What happens to existing data when I change field permissions?
Changing field permissions doesn’t affect existing data. The data remains intact, but future edit capabilities change based on the new permission settings.
Can collaborators see which fields have restricted permissions?
Yes, users will see visual indicators on fields they cannot edit, making it clear which permissions are in place.
Related content
Based on your interest in field-level permissions, you might also find these features helpful:
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.