Rows Within the Model
Row-level access decides which individual records somebody may reach. The roles and grants are covered under Record Access Roles; this article is about when the layer is needed and how it composes.
Where to find it
Architect Panel → Security:
- Record Access Roles — the roles and per-record grants
- Permissions — the datastore layer above it
Architect Panel → Data:
- Datastores — datastore-level access
The question it answers
Datastore permissions say somebody may work with cases. Row-level access says which cases. Without it, anybody who can open one case can open all of them.
It narrows, like the others
A record-level grant does not give access to a datastore the person cannot otherwise reach. Both must permit it. When a grant appears to have done nothing, the datastore layer is the first thing to check.
When a datastore needs it
- Records belong to teams, regions or services and should not be visible across them.
- Records concern individuals, and staff should see only those they are working with.
- External users see their own records through a portal.
- Sensitivity varies between records of the same kind.
The alternative to avoid
The instinct is to solve this by splitting the datastore — cases per team, per region, per service. It works until it does not:
- The same fields are defined many times and drift apart.
- Reporting has to union everything back together.
- A record cannot move between teams without being recreated, losing its history.
- Every new team means a new datastore, forms, views and permissions.
One datastore with row-level access avoids all of it, and a record moving between teams is a change of grant rather than a migration.
Grant to groups and teams
A grant can name an individual, a security group or a team. Prefer the latter two: individual grants become stale the moment somebody changes role, and nobody goes back to tidy them.
Use reasons and expiries
Per-record grants accumulate faster than any other kind, because they are made in the flow of ordinary work rather than as an administrative decision. A reason makes them reviewable and an expiry makes them self-clearing — without both, a record ends up accessible to people nobody chose.
Combine the layers deliberately
The three layers compose into precise access: a caseworker may work with cases (datastore), may see their own team's (row), and may not see the financial assessment on them (field). Each layer answers a different question, and trying to make one of them do another's job is where configurations become unmanageable.
Worked example
An organisation with six service teams keeps one case datastore. Each team is granted access to its own cases through a team role; escalations add the safeguarding group as reviewer with a reason and an expiry. Reporting runs across every case in one query, and a case transferred between teams keeps its full history.
Recommendations
- One datastore with row-level access, not one per team.
- Grant to groups and teams rather than individuals.
- Always record a reason and set an expiry.
- Let each layer do its own job.