Restrict column access: Field-level permissions in Baserow

Efficient data governance requires a delicate balance between transparency and security. If you are migrating your workflows from standard spreadsheets or legacy project management tools, you are likely familiar with the risk of “all-or-nothing” access: if a user can edit the database, they can edit everything.

Baserow solves this through granular field-level permissions. This specialized security layer allows you to give users access to a table while strictly restricting who can view or modify specific columns; such as pricing margins, sensitive PII, or internal approval statuses.

Here is how you can use field-level security to maintain a single source of truth without compromising data integrity.

Moving beyond all-or-nothing access

Field permissions sit directly on top of Baserow’s existing workspace hierarchy. By defining access through Role-Based Access Control (RBAC), you determine exactly who has the authority to interact with a specific column:

• Admins Only: Only workspace, database, or table administrators can make changes.
• Builders and Higher: Restricted to Builders and Admins.
• Editors and Higher: Allows Editors, Builders, and Admins to modify data.
• Read-only (Nobody): Completely locks the field; no manual edits are permitted by any user, which is ideal for strict audit trails.

Strategic use cases for field-level security

Implementing granular access controls is critical for teams handling customer data or heavily regulated information (like GDPR and HIPAA compliance).

• Progressive Approval Workflows: In a content pipeline, different fields are locked as they move through business stages. A “Draft link” field stays open to Editors, but the “Final Approval” checkbox is restricted solely to Admins.
• **Human Resources & ATS:** Manage sensitive data flows by allowing the entire team to see an applicant’s name and interview stage, while completely hiding or locking the “Salary Requirements” column to top-level management.
• **Financial Auditing:** Create a tamper-proof environment by setting “Audit Status” or “Reimbursement Paid” fields to Read-only, ensuring financial trails cannot be accidentally or maliciously overwritten.

Locking down forms and API integrations

Field permissions extend far beyond the web interface; they actively protect your internal data integration points.

Security in the Form Designer

If a field is restricted to “Admins only,” it automatically becomes unavailable to general users in the form designer. This ensures that public data entry remains strictly within your governance rules—submitters cannot even see or fill fields they are not authorized to edit.

Strict Baserow API enforcement

The Baserow API rigorously respects these security settings. Whether it is a simple REST API call or a complex Zapier/Make integration, any external request attempting to modify a restricted field will immediately return a FIELD_NOT_EDITABLE error. Your automation scripts can never bypass your internal security protocols.

Frequently asked questions about field security

How do I restrict edit access to specific columns without locking the whole database?

Unlike basic spreadsheets that require you to lock an entire sheet, Baserow allows you to apply field-level permissions. This means you can invite team members to collaborate and edit standard columns (like task names and due dates) while strictly locking sensitive columns (like budgets or personal contact info) to Admins only.

If I restrict a column’s edit permissions, what happens when I build a public form?

Baserow seamlessly applies your security rules across the platform. If a specific field is set to a permission level higher than the form creator’s role, that field simply cannot be added to the public form. This prevents unauthorized users from accidentally exposing internal fields to public data collection.

Can I hide a column completely from certain users, or just stop them from editing it?

Yes, you can do both. You can use field permissions to dictate exactly who can edit the data, and combine that with specific database views to visually hide the column from your team’s day-to-day workspace, improving both security and the user experience.

How does field-level security protect against API overwrites and accidental data loss?

If you have automated workflows pushing data into Baserow via the API, field-level permissions act as a fail-safe. If an automation attempts to overwrite a column that has been restricted to “Read-only” or “Admins only,” the Baserow API will block the action and return an error, keeping your critical data safe from rogue scripts.

To learn more about advanced security configurations, visit the Baserow Documentation.