Baserow Views: Separate Layout from Access

Keep one table and multiple working layouts

Baserow’s official views overview describes different presentations of the same underlying table, with independent view settings. Editing a record is a data change, whereas changing a view’s filter changes its presentation. The overview also distinguishes collaborative, personal and restrictive view concepts; availability needs checking for the chosen edition.

Hypothetical example: a service team works from one Jobs table. Dispatch needs today’s scheduled work, finance needs unbilled jobs, and a manager needs outstanding follow-ups. Separate layouts can help each person without maintaining three copied job lists that gradually disagree.

Documentation: Baserow: Views overview

Specify what each view is for

Give a shared view a task-based name and a short rule: “Unbilled completed jobs” is clearer than “Main copy 3.” Define which state transitions should make a row appear or disappear. If a row vanishes after editing, the filter may have become false rather than the data being deleted.

Test with synthetic jobs in several states. Change one job from Scheduled to Complete and inspect the relevant views. Record the expected movement. A view is useful when staff can predict what it shows and explain a missing record.

1. Identify the workflow decision each view supports.
2. Choose fields, ordering and filters appropriate to that decision.
3. Create sample rows that should appear and sample rows that should not.
4. Change a sample state and inspect the resulting view membership.
5. Document who may change the shared configuration.

Use a separate access review for restricted data

The permission documentation describes plan-dependent authorization features. If a dispatcher must not read financial information, an ordinary presentation setting is not the acceptance test. Identify every relevant path: another view, a direct table link, a shared link and an integration credential.

Documentation: Baserow: Permissions overview

Diagnose layout problems before copying data

When a colleague cannot find a job, first compare the table, filter, sort and active view. Creating a second table to “fix” a filter issue introduces a new synchronization problem. Keep the stable row ID in the troubleshooting record so both people can discuss the same entity.

Reserve a clearly documented recovery path for accidental configuration changes, such as a known baseline view whose purpose is understood by its maintainers. Do not turn that baseline into a broader permission grant. Layout recovery and access authorization are different decisions.

This guide explains a view-design method. It does not certify row-level isolation, validate a particular plan or report a completed user-access test. Those claims require the actual edition and accounts.

Hypothetical Jobs view specification

This is an illustrative worksheet to adapt to your own evaluation. It is not a measured product test or a claim about results in your installation.

Use views to make work clearer, and use an explicit permission test to establish who can access the data.