Datastore-level permissions are the broadest control: whether a security group can interact with a table at all. For 80% of permission configuration, this layer is where the work happens. Get datastore permissions right first; add field- and row-level rules later only where needed.
The four core actions
Every datastore-level permission grants one of four actions, with the option to mix and match per group:
- Read — see rows in browse views, the API, and detail pages. Without Read, the datastore is invisible to the group.
- Write (create) — add new rows. The user can fill in the New Record form and save.
- Edit — change existing rows. The Edit button appears in row actions; the user can open the edit form and save changes.
- Delete — soft-delete rows. The Delete button appears in row actions.
Granting transitively
The four actions don't auto-imply each other — granting Edit doesn't automatically grant Read — but in practice you almost always want them to align:
- Write usually requires Read so users can see what they're creating against.
- Edit always requires Read — there's no point letting someone change a row they can't see.
- Delete usually requires Read and Edit for the same reason.
The platform doesn't enforce these alignments — you can have illogical combinations — but you should configure them deliberately rather than by accident.
Where to configure
From the Architect Panel → Datastores admin, find the datastore and click the Permissions button. The Permissions dialog opens with rows for each existing security group.
For each group, tick the actions the group should have. Save. Permissions take effect immediately on the next request from any user in that group.
Three real-world permission matrices
Example 1: Orders table on a B2B platform
Different groups need different access:
- Sales Team: Read, Write, Edit. Can create new orders and update them.
- Finance Team: Read, Edit. Can view all orders and update payment status, but can't create orders.
- Customer Service: Read only. Can see orders but can't change them.
- Customers (external): Read only, plus row-level security restricting them to their own orders.
- Anonymous Visitors: No access at all.
Example 2: Internal knowledge base articles
- All Users: Read. Anyone logged in can see the articles.
- Knowledge Base Editors: Read, Write, Edit, Delete. Full control.
- Anonymous Visitors: No access (internal-only).
Example 3: Customer profiles
- All Users: No access — customer data is sensitive.
- Customer Success Team: Read, Edit. View and update customer details.
- Sales Team: Read only. Can see customer history when prospecting.
- Finance Team: Read only.
- Customers themselves: Read, Edit on their own row only (via row-level security).
Audit and review
Datastore permissions are one of the highest-leverage places to make a mistake — accidentally granting Write to a customer-facing group on the wrong table can leak data. Two practices to mitigate:
1. Review after every change
After granting or revoking permissions, click around as a representative user from each affected group. Verify they see what they should and don't see what they shouldn't.
2. Periodic audit
Quarterly, export the full permission matrix and review it with whoever owns the affected business function. People change roles, applications evolve — permissions need to keep up.
Note: The platform doesn't enforce that you read what you write — you can have a group that can create rows but can't see them afterwards. That's occasionally useful (anonymous form submissions are an example) but more often a misconfiguration. Spot-check the matrix for any group with Write but not Read.