Authorization & Permissions

This guide explains every control the CRM gives you for deciding who can do what and who can see which records. It’s written for workspace admins.

If you only remember one thing: the system answers two independent questions, and it’s worth keeping them separate in your head.

1. What can this person do? (create records, manage tables, invite members…) — governed by actions, granted through roles.

2. Which records can this person see and edit? — governed by record visibility, record scopes, and sharing.

A person needs to pass both checks. Being allowed to “edit records” (question

means nothing if none of the records are visible to them (question 2), and vice-versa. Everything below is one or the other of these two questions.

The setting: organizations vs workspaces

An organization is the billing/management grouping. Org roles (owner / admin / member) control the organization itself — creating workspaces, managing billing, inviting people to the org. Org roles grant no access to workspace data.
A workspace is where your data lives (tables, records) and is the permission boundary. Everything in this guide is about workspace permissions.

To use a workspace at all, a person must be an organization member who has been granted access to that workspace. That grant carries a workspace role (see below). Adding someone is therefore two things — joining the organization, and being granted workspace access — though an invitation can do both at once: pick the workspaces (and the role in each) on the invite, and they are applied the moment it is accepted.

Once somebody is already in the organization, widening their access is a grant, not another invitation: Organization Settings → Workspaces → Manage members.

What an org owner or admin can do to a workspace

An org owner/admin administers every workspace the organization owns, from Organization Settings → Workspaces: rename it, and manage its members — add, change roles, remove, restore — without being a member of it themselves.

They still cannot open it. Administering a workspace and having access to the data inside it are deliberately separate: reading or writing records always requires a workspace membership. When an org admin does need to work in a workspace, Join workspace adds them as a workspace admin — an ordinary membership that appears in that workspace’s own member list, so nobody has access that the people in the workspace cannot see.

Removing somebody from the organization removes them from every workspace it owns, immediately, along with any API tokens they held there.

Lever 1 — The membership role (the baseline)

Every workspace member has exactly one membership role, shown in Workspace Settings → Members:

Role	In one line	Can it administer the workspace?
Admin	Full control of the workspace and its data.	Yes
Member	Create and edit data, tables, charts, queries.	No
Reader	View-only.	No

This is the baseline for that person. It’s the fastest way to set someone’s overall level, and for most people it’s the only lever you’ll ever touch.

Change it with the Edit role action on the Members tab.

Each role is additive: a Reader can do a subset of what a Member can, which is a subset of what an Admin can.

What each baseline role grants

Roles don’t grant vague “levels” — under the hood each grants a specific set of named actions (see Lever 2). The built-in roles grant:

Reader — read-only actions: view records, tables, charts, saved queries, attachments, groups, members, and the audit log.
Member — everything Reader has, plus create/update/delete records, create and manage tables and fields, manage charts/queries/attachments, and create API tokens.
Admin — everything Member has, plus manage members, manage groups, apply schema plans, and manage permissions (roles, record visibility, field visibility).

Lever 2 — Actions (the vocabulary underneath roles)

Every capability in the system is a named action, like records:create, tables:manage, or workspace:members:manage. Roles are just named bundles of actions. The API and the audit log speak in these action names, and the UI hides buttons you don’t have the action for.

You rarely deal with actions directly — you deal with roles. But they’re the common currency: a “role” is nothing more than a checklist of actions.

A person’s effective actions are the union of every role they hold (see Lever 3). There is no “deny” — you grant capabilities, you never subtract them.

Lever 3 — Custom roles (extra capabilities on top of the baseline)

Sometimes the three baselines aren’t enough. Example: you want a Reader who can also create records in one workflow, but nothing else. Rather than promoting them to full Member, you create a custom role that grants just records:create and assign it to them.

Custom roles are purely additive. A person’s real permissions are:

their membership role ∪ every custom role assigned to them

So the Reader-plus-records:create example ends up able to read everything a Reader can and create records — but still can’t, say, delete tables, because no role they hold grants that.

Manage custom roles in Workspace Settings → Roles: create them (tick the actions they should grant), and assign them to members.

Why “Admin / Member / Reader” also appear on the Roles tab

The Roles tab lists five roles for a fresh workspace: the three built-in ones (Admin, Member, Reader) plus any custom roles you’ve created. The three built-ins are shown so you can see exactly which actions each baseline grants — they are the definition of the baseline, not a separate thing.

They show “0 assigned” on purpose. The membership role (Lever 1) is stored on the member, not as a role assignment, so the built-in roles legitimately have zero explicit assignments even though everyone has one as their baseline. Only custom role assignments are counted here. (See the FAQ — this is the single most confusing part of the current UI.)

The built-in roles are locked: you can look at what they grant but not edit or delete them.

Lever 4 — Table record visibility (who sees which rows)

This is question 2 — visibility, not capability. It’s set per table.

Each table has a Record visibility setting (in the table’s settings dialog, visible to admins):

Workspace (default) — every member who has record-read access sees all rows in the table. This is the classic “shared CRM” behavior.
Private — a member sees only the rows they own (the person who created a record owns it by default), plus anything explicitly granted to them by a scope or a share (below).

Switching a table to Private is what turns on all the finer-grained visibility machinery for that table. On a Workspace table, scopes and shares are irrelevant — everyone sees everything.

Admins always see all rows, on every table, private or not. This is the deliberate “manager can see everything” escape hatch. Only admins have it.

Lever 5 — Record scopes (how far a role’s visibility reaches)

On a private table, a role’s record scope decides how far past “just my own records” that role can see, per operation (read / update / delete). The scopes, from narrowest to widest:

Scope	Sees / can act on…
none	Nothing (not even own).
own	Only records they own.
group	Records owned by anyone who shares a group with them.
workspace	All records in the table.

The built-in baselines set this automatically: Reader and Member get own (they see their own records on private tables), and Admin gets workspace (sees all). Custom roles default to own and can be widened per operation when you create them — e.g. a “Team Lead” custom role with read = group lets its holders read every record owned by their teammates.

Because roles are additive, a person’s scope on a table is the widest scope any of their roles grants.

Scopes rely on groups (Workspace Settings → Groups) to define “team”. A group scope means “people I share at least one group with”.

Scopes are rules that apply to whole roles. Sharing is a per-record exception: on any record you can update, use Share (on the record detail page) to grant one specific person or group view or edit access to that one record — regardless of scope.

Shares are additive and take effect immediately. Use them for “let Bob see this one deal” without changing anyone’s role. Remove a share and access disappears on the next request.

Lever 7 — Field visibility (hiding columns)

Visibility can also apply to a single field/column, independent of rows. Each field has a visibility setting:

Workspace (default) — anyone who can see the record sees this field.
Private — the field is hidden from members (and rejected on write) unless a role explicitly grants access to it.

A private field is masked everywhere — list views, detail views, exports — so it never leaves the server for someone who lacks access. Use it for things like salary or internal notes.

Grant a role access back to a private field in Workspace Settings → Roles (the role’s field grants), which can allow read and/or edit.

Admins always see all fields, private or not — same escape hatch as rows.

Set a field’s visibility in the table’s schema editor (see the FAQ — the control is the Visibility chip in the fields grid).

How it all combines

For a given person, on a given table:

Can they do the action at all? Union of their roles’ actions must include the operation (e.g. records:update). If not → denied.
Which rows? If the table is Workspace-visibility, all of them. If Private: rows they own, ∪ rows within their widest role scope (own/group/workspace), ∪ rows shared to them. Admins: all rows.
Which columns? All fields except private fields they haven’t been granted. Admins: all fields.

Two guiding principles:

Additive, most-permissive-wins. More roles/shares can only widen access. There is no deny list.
Admins bypass the row and field filters (not the action checks — but admins have all the actions anyway). This is the intentional escape hatch; keep the Admin role scarce.

Everything is enforced on the server. The UI hides controls you can’t use as a convenience, but the server is the source of truth — a hidden button that’s somehow clicked still returns “forbidden”.

Worked example

You run a sales team. You want reps to only see their own deals, team leads to see their whole team’s deals, and managers to see everything.

Set the Deals table to Private visibility.
Put each team’s members in a Group (e.g. “EMEA”, “AMER”).
Reps are Members — baseline own scope means each sees only their own deals.
Create a custom role “Team Lead” with read = group scope, assign it to the leads. They now read every deal owned by a teammate (same group), on top of their Member baseline.
Managers are Admins — they see all deals automatically.
For a one-off (“let Finance see this single deal”), the deal owner uses Share.

Where to manage each lever

Lever	Where
Membership role	Workspace Settings → Members → Edit role
Custom roles & assignments	Workspace Settings → Roles
Field access grants for a role	Workspace Settings → Roles → (role) → field grants
Table record visibility	The table’s settings dialog (table list → edit table)
Field visibility	The table’s schema editor → Visibility column
Groups (for `group` scope)	Workspace Settings → Groups
Record sharing	The record’s detail page → Share

FAQ / known rough edges

Q: The Members tab shows someone as “Member”, but the Roles tab doesn’t list them under the Member role — and a custom role I assigned them doesn’t show on the Members tab at all. Are there two different role systems?

No — there’s one system, but it’s currently shown in two places that don’t cross-reference, which is genuinely confusing:

The membership role (Members tab) is the person’s baseline — stored on their membership record. It’s one of Admin/Member/Reader.
The Roles tab shows role definitions and custom-role assignments. The built-in Admin/Member/Reader entries there are the definitions of what each baseline grants, which is why they read “0 assigned” (baselines aren’t counted as assignments). Custom roles are the extra, additive layer, and their assignments are shown there.

So a person can be “a Member (baseline) who also holds the custom ‘Data Entry’ role”. Today the Members tab only shows the baseline and the Roles tab only shows the custom assignment. Surfacing a person’s custom roles on the Members tab is a planned improvement.

Q: My table’s fields say “Workspace” but I can’t find where to change it.

Open the table’s schema editor (not the record list — the page where you add and edit fields). Each field row has a Visibility column showing a Workspace / Private chip. If you have permission to manage permissions (Admins do), clicking the chip toggles it. If the chip isn’t clickable, your account lacks the permissions:manage action. Making this control more obvious (and adding it to the field-edit dialog) is a planned improvement.

Q: Why can a Reader still see everything on some tables?

Because those tables are Workspace visibility (the default). Record scopes only take effect once you switch a table to Private.

Q: I removed someone’s role but they can still act.

Permissions are cached briefly per workspace and refreshed on changes; if something looks stale, it resolves within moments. Note also that Admins bypass row/field filters entirely — check whether the person is an Admin.

Open the app