Evaluate whether the exact Baserow edition supports the required separation of responsibilities.
Check the edition before designing restrictions
The official permissions overview distinguishes basic workspace roles from more granular role-based access. It ties granular capabilities to particular plans. Verify the deployment and licensed entitlement you intend to operate instead of transferring a paid cloud demonstration to a community installation.
Hypothetical example: a small agency needs coordinators to edit project schedules while finance staff manage billing information. An external reviewer should read an approved subset without changing structure. These are three distinct requirements; “team collaboration” does not describe the necessary boundaries.
Documentation: Baserow: Permissions overview
Specify actions, resources and expected denials
List operations explicitly: view a record, create one, change a field, delete a row, alter a table and invite a person. Some roles combine actions that your workflow would prefer to separate. Discovering that mismatch during evaluation is more useful than discovering it after real confidential information is added.
Use synthetic records with obvious labels, such as FINANCE-ONLY-SAMPLE. A test should establish both that the authorized role can complete its work and that another role cannot reach that sample through the paths being assessed. Perform the test from separate browser sessions so administrator state does not contaminate the observation.
- Record release, edition and the requirement owner.
- Create disposable sample accounts for each intended role.
- Assign the smallest supported access needed for the job.
- Test allowed operations and specified denials through relevant routes.
- Record actual results, exceptions and any need for a different architecture.
Review exceptions and inherited access
A person can gain access through more than one assignment. Review direct grants, team membership, shared links and integration credentials relevant to the resource. A narrow label in one screen should not be the only evidence in an access review.
Choose a response for unmet requirements. Possibilities include changing the workflow, separating data into a different resource, using a supported higher edition or rejecting the candidate. Merely hiding a field is not an acceptable substitute when the requirement is to deny access to its contents.
Repeat the matrix after material permission, membership or edition changes. Record who approved the intended model and who performed the checks. This process supports a defensible software decision; it is not a legal compliance audit or a guarantee that every possible access path has been evaluated. Keep the scope of the test visible.
Hypothetical agency permission matrix
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.
| Role | Allowed task | Denial to verify |
|---|---|---|
| Coordinator | Update schedule samples | Read restricted billing sample |
| Finance | Maintain billing samples | Unnecessary administration |
| External reviewer | Read approved sample | Edit data or structure |
| Integration | Specified row operation | Unrelated table access |
Choose the edition from the required access model, then verify that model using the actual roles and paths.
Inspect the official interface evidence
These previously captured interfaces provide orientation. Their versions and dates are distinct from the documentation review above.
Inspect the interface, with its context.
Open a specimen to see the source image and the observations it supports. A vendor demonstration is distinct from a self-hosted installation.
BaserowOfficial live template · Demo version not disclosed
- Table navigationThe sidebar separates the demo’s task-management examples.
- View controlsFilter, sort, group and hide-field controls are visible in this preview.
- Calculated fieldsFormula columns display generated task names and identifiers.
Check the facts and their boundaries.
Official documentation supports the product statements. The evaluation procedures and synthetic examples are editorial guidance. We have not independently run the installation, migration or recovery procedures described here.
Basic versus granular roles as described by the current documentation; verify purchased/self-hosted entitlement. Reviewed 2026-11-01.