Row-Level Access
Datastore permissions answer "may this person work with cases at all". Record access answers "may they see this case". They are different questions and they need different mechanisms.
Where to find it
Architect Panel → Security:
- Record Access Roles — the roles defined per datastore, and their default level
- Permissions — datastore-level grants, which come first
Architect Panel → Data:
- Datastores — the Permissions row action, for datastore-level access
Why datastore permissions are not enough
Grant a social worker access to the case datastore and, without row-level control, they can see every case in the organisation. That is rarely what anybody intends, and in regulated work it is a reportable problem rather than an inconvenience.
The instinct is to solve it by splitting one datastore into several — cases per team, per region, per service. Resist it. You end up with the same fields defined many times, reporting that has to union everything back together, and a record that cannot move between teams without being recreated.
Roles are defined per datastore
A record access role is a named kind of relationship somebody can have with a record in a particular datastore — owner, assignee, reviewer, observer — each carrying a default access level and an order.
Defining roles first means grants become meaningful rather than numeric. "Priya is a reviewer on this case" is something a person can read and judge; "Priya has level 2" is not.
Grants attach a principal to a record
A grant records who has access to which record. The principal can be:
- An individual, identified by the same three-part identity used throughout the platform.
- A security group.
- A team.
Granting to a group or team is almost always better than granting to individuals. People join and leave; a record granted to fifteen named individuals becomes a maintenance problem the moment somebody moves on, and nobody goes back to tidy it.
Both layers must permit it
Row-level access does not override datastore permissions — it narrows within them. Somebody with no permission on the case datastore is not granted access by a record-level grant, and this is the usual explanation when a grant appears to do nothing.
Check the datastore layer first when a grant is not working. It is the more common fault by a distance.
Design the roles before granting anything
Three or four roles usually cover a datastore. Write down what each is allowed to do before creating them, because roles get used as soon as they exist and changing what one means afterwards silently changes existing grants.
Worked example
A council's case datastore defines owner, co-worker, reviewer and observer. A complex case is owned by one social worker, with the safeguarding team granted as reviewer. When the case is escalated, the escalation team is added as co-worker rather than the case being copied — so it stays one record with one history.
Recommendations
- One datastore with row-level access, not one datastore per team.
- Define roles before you start granting.
- Grant to groups and teams, not to individuals, wherever you can.
- Check the datastore layer first when a grant seems ineffective.