Access Control lets you decide exactly which roles can see an entity's golden records, which of those records they can see, and which fields within them are visible — all from a single policy editor.
Overview
Every entity in your Ontology model has its own Access Control tab, found under the entity's Settings. From there you can create any number of policies, each combining a set of roles with a record-level filter and a field-level rule. Click New Access Control to start one from scratch. Existing policies show up in a list where you can open them to edit, or delete them — deleting asks for confirmation first, since the action can't be undone.
The Setup Steps
Creating a policy walks you through four steps, in order:
Info — give the policy a name and a short description so your team can tell policies apart later.
Add Roles — choose the user roles the policy applies to. Everything you configure after this step applies only to these roles.
Record Access — set filter conditions that decide which records the selected roles are allowed to see.
Field Access — choose which fields on those records the selected roles can view.
You can move back and forth between steps before saving, and revisit any of them later by editing the policy.
Record Access
The Define Record Access step is where you set row-level security. You build one or more filter conditions over the entity's fields — the same kind of conditions you'd use anywhere else in the platform to narrow down records. Only the records that match your conditions become visible to the roles attached to this policy; everything else stays hidden from them, regardless of what their field-level access allows.
Field Access Modes
The Define Field Access step controls which attributes are visible on the records a role can already see. You choose one of two modes, then tick the fields that mode applies to.
| Mode | What it does |
| Allow only selected fields | The role can see only the fields you tick — every other field is hidden. |
| Don't allow selected fields | The role can see everything except the fields you tick. |
Only scalar fields show up in the field picker — array and JSON fields aren't offered, so field-level access can't be scoped to them.
Notes
A policy only takes effect for the roles you add in Add Roles — roles left out of every policy keep their default access to the entity.
Record Access and Field Access work independently: a role still needs to pass the record filter before its field permissions matter at all.
Deleting a policy is permanent and asks for confirmation — there's no undo.
Array and JSON fields are always excluded from field-level access controls; they aren't selectable in either mode.
You can create multiple policies for the same entity to cover different roles or scenarios.