Skip to content

Per-Record Sharing

Per-record sharing lets you grant access to a single record — to a user, a role, a team, or everyone — on top of the role-based permission model. Use it when someone needs one specific deal, ticket, or document but shouldn’t get broad table access. Record shares are additive: they only ever widen access, and only for the record they name.

Each share is a grant attached to one record. A grant names a grantee and the operations it confers:

Grantee typeWho it shares with
userone specific user (by id)
roleeveryone holding a role
teameveryone on a team
allevery authenticated user

Operations are the standard set: read, create, update, delete.

GET /api/apps/{app}/tables/{table}/records/{record_id}/shares # list shares
POST /api/apps/{app}/tables/{table}/records/{record_id}/shares # add a share
DELETE /api/apps/{app}/tables/{table}/records/{record_id}/shares/{grant_id} # remove a share
POST .../records/{record_id}/shares
{
"grantee_type": "user",
"grantee_id": "<user-uuid>",
"operations": ["read", "update"]
}

A per-record grant has priority 300 — above an application-level grant (100) but below a table-level grant (500). It adds access to its one record; it never removes access. See Permissions for the full priority ladder.

Sharing cannot be used to escalate privilege:

  • To manage a record’s shares, you must have update permission on the table.
  • You can only share a record you can actually see — record-level row security is checked, so you cannot share a record you have no access to.
  • You can only grant operations you yourself hold on that record. You cannot, for example, share delete if you do not hold delete, or share an operation with all that you lack.
  • Removing a share is scoped to the record in its URL, so a grant on one record can never be deleted through another record’s endpoint.
  • Permissions — role, table, and field-level access and priority resolution
  • Users & Roles — the users, roles, and teams a record can be shared with