Permissions & Access
Control who can see and edit your data at every level.
How permissions work
Sajel uses a layered permission system. Access flows down from your account to workspaces, bases, tables, columns, and rows — with the ability to override at every level.
By default, permissions inherit downward. A workspace Editor is automatically an Editor on every base and table in that workspace — unless someone explicitly overrides it at a lower level.
Most teams only need to set workspace-level roles. Override at the base or table level only when you need to restrict or elevate access for specific data.
Roles
There are four roles, used at the workspace, base, and table levels:
Be careful with the Owner role — Owners can manage permissions and invite other members.
Inviting people
Open the Share button on any workspace, base, or table. You have two options:
Add an existing member
Start typing a person's name. If they're already in your account, they appear in the autocomplete dropdown showing their name and email. Select them, choose a role, and they're added instantly.
Invite someone new
Type a full email address. If they're not in your account, you'll see an "Invite as external user" option. They'll receive an email with an invitation link that expires after 7 days.
When inviting at the workspace level, new members automatically get access to all bases in the workspace based on the role you assign. You can narrow this down afterwards.
Scoping access: all or specific
When assigning a workspace role, you can choose whether it applies everywhere or only to specific bases:
The same pattern works at the base level — you can scope access to all tables or specific tables.
To set this up, open Manage Access on a workspace or base, change someone's role, and you'll see the scope picker appear.
Column permissions
Column permissions control who can see and edit individual fields within a table. Right-click a column header and select Field permissions.
Visibility — who can see this field?
Editability — who can edit this field?
Column permissions are enforced on the server. Hidden columns are stripped from API responses before reaching the browser — the user never receives data they shouldn't see.
Row-level access filters
Row filters restrict which records a user can see within a table. Owners always see all records.
To configure filters, open the board menu and select Access Filters. Add rules like:
If no filter is configured for a user's role or group, they see all records by default.
Only table Owners can configure access filters. Editors and Viewers cannot see or change these settings.
View visibility
When saving a view (filters, sorts, and column configuration), you can set its visibility:
Views layer on top of other permissions. A shared view still hides columns or rows the user doesn't have access to.
Groups
Groups are collections of users defined at the account level. They make it easy to manage access for teams.
Account Admins create groups in Account Settings > Groups. You can then assign a group a role on any workspace, base, or table — just like an individual user.
When a user has permissions from multiple sources (their individual role + group roles), the most permissive role wins. For example, if someone is an Editor individually but their group is set to Owner, their effective role is Owner.
Exception: An individual No Access overrides everything — including group roles. This gives Owners an escape hatch to block a specific person regardless of their group memberships.
Quick reference
| Capability | Owner | Editor | Viewer | No Access |
|---|---|---|---|---|
| View records | ✓ | ✓ | ✓ | ✗ |
| Create / edit records | ✓ | ✓ | ✗ | ✗ |
| Add comments | ✓ | ✓ | ✓ | ✗ |
| Create views | ✓ | ✓ | ✗ | ✗ |
| Create / edit fields | ✓ | ✗ | ✗ | ✗ |
| Manage permissions | ✓ | ✗ | ✗ | ✗ |
| Create automations | ✓ | ✗ | ✗ | ✗ |
| Invite members | ✓ | ✗ | ✗ | ✗ |
| Publish forms | ✓ | ✗ | ✗ | ✗ |