Datastore Permissions
Datastore permissions decide whether a group may work with a kind of record at all. Everything else narrows within them.
Where to find it
Architect Panel → Data:
- Datastores — the Permissions row action on each datastore
Architect Panel → Security:
- Permissions — the named permissions a grant is composed of
Where it is configured
Architect Panel → Data → Datastores, then the Permissions row action on the datastore you want. Not from a menu — this is one of many places the platform surfaces functionality as a row action.
What a grant contains
A grant ties a group to a datastore and lists the named permissions it holds there. Those permissions are the specific capabilities — reading, creating, editing, deleting and so on — rather than a single level.
Because it is a list, a group can hold some capabilities and not others. Read without delete is an ordinary configuration, and it is worth using: most people who need to see records do not need to remove them.
Get this layer right first
Field and row restrictions are refinements. If the datastore layer is wrong, nothing below it can rescue the situation — and a group granted access to a datastore it should not touch at all is a much larger problem than a misconfigured field.
Delete deserves its own decision
It is the capability people grant without thinking, because it arrives alongside edit in most mental models. Deletion is soft here — records go to Trash — which makes it recoverable, not harmless.
Grant it to the groups that genuinely need to remove records, which is usually fewer than have edit.
Start from nothing
A new group should begin with no datastore access and gain what it needs. Copying another group's grants carries across everything that group accumulated, including whatever nobody has reviewed.
Review by datastore, not by group
Both views are useful, but reviewing per datastore answers the question that matters: who can reach this? For a sensitive datastore, that list should be short and every entry should be explicable.
Reviewing per group tends to confirm what you expected; reviewing per datastore surfaces the group you had forgotten about.
Watch for grants to All Users
A datastore granted to the All Users group is granted to every account, including ones created in future, and it cannot be found by reviewing membership because that group has none. Check for it explicitly.
Worked example
A review of a supplier datastore lists five groups with access. Three are expected. One is a project group whose project ended. One is All Users, added years earlier so that staff could look up contact details — which now means every account can read supplier bank references. Both are corrected, and the review is scheduled annually.
Recommendations
- Fix this layer before configuring anything below it.
- Grant delete deliberately, to fewer groups than edit.
- Review per datastore, not only per group.
- Check for All Users grants explicitly.