Access Policies

Access policies decide which rows of a table each person can see, inside data that’s already been shared with them. A store manager sees their store, a regional lead sees their region, and someone with no policy sees everything. It’s one table, filtered for each person.

Who can use this: organization admins. Open Settings from your avatar menu, then Security → Access Policies.

No policies means full access

Until someone is assigned a policy, they see every row of the data they can open. Policies only ever take rows away. The empty page says it directly: “Without policies, all users have full access to all data.”

1. Access Policies and Audit Log: the two tabs on the Security page.
2. Preview Access: see the filter a person would get.
3. Create Policy: add a policy.
4. Applies To: whether a policy covers sources automatically or only the ones you pick.

How a policy works

A policy is a rule with three parts: a column, the values allowed in it, and the people it applies to.

Say a policy on region allows SE. Anyone assigned to it sees only the rows where region is SE, in every source the policy covers.

The policy list shows each policy’s Name (with its description), its Row Filter, written like region IN (SE), whether it Applies To sources automatically (Auto) or only to chosen ones (Explicit), and how many Users it has. Use the pencil to edit a policy and the trash can to delete it.

Create a policy

1. Click Create Policy, or Create Your First Policy if there aren’t any yet.
2. In Create Access Policy, enter a Name and, if you like, a Description.
3. Under Row Filter, enter a Column Name, like store_id or region, and the Allowed Values (comma-separated). Fill in both or neither.
4. Under Applies To, choose Auto or Explicit. With Explicit, pick the Sources it covers.
5. Click Create.

If the dialog stays open after you click Create, the policy wasn’t saved. The dialog doesn’t show an error message.

1. Name: what the policy is called.
2. Row Filter: the column, and the values allowed in it.
3. Auto: cover every source that has that column.
4. Explicit: cover only the sources you pick.

This dialog takes one column per policy. To filter on two columns, make two policies and assign the same people to both.

Auto or Explicit

Auto, the default, applies the policy to every source that has a column with that name. Column names match regardless of case, so a policy on Region also covers region.

Explicit applies it only to the sources you pick. Use it when the same column name means different things in different sources.

Assign people

Click the number in a policy’s Users column. Search by name or email and pick someone to add them. Picking assigns them straight away, and clicking ✕ next to a name removes them straight away. There’s no save step.

Policies are assigned to people one at a time.

1. The user picker: picking someone assigns them straight away.
2. The assigned list: who the policy applies to.

How policies combine

A person can have several policies. On the same column, the allowed values add up: policies allowing region SE and region NE show rows from either region. On different columns, every one must match: region SE plus department Sales shows only rows that match both.

A policy that doesn’t apply to a source, such as an Auto policy on a column the source doesn’t have, doesn’t filter that source.

Preview Access

Preview Access shows the filter a person would get on a source. Pick a User and a Source, then click Resolve Access.

The result either says the person has full access, because they have no policies or none apply to that source, or shows the Generated WHERE clause: that Querri adds to their queries. It shows the filter, not the rows.

Sources that require a policy

A source can be set to require an access policy. There’s no setting for it in Settings. It’s set through the API, with PATCH /api/v1/sources/{id} and access_controlled set to true, using a key with the admin:sources:write scope. Anyone without a matching policy then sees no rows from that source. Preview Access doesn’t account for this yet: for such a source it can report full access for someone who is actually blocked.

1. User: the person to check.
2. Source: the source to check.
3. Resolve Access: show the filter they’d get.

Dashboards, links and API keys

On a dashboard, each viewer’s own policies apply. See Dashboard Security.

Through a public link, visitors see the data filtered by the policies of the person who made the link.

An API key isn’t filtered by the policies of the admin who created it. Only policies assigned to the key itself apply, and customers can’t assign one yet. See API Keys.

What’s recorded

Creating, changing and deleting a policy, and adding or removing people, are all written to the Security audit log.

Next steps

• Dashboard Security: how shared dashboards apply each viewer’s policies
• Filters: filters that apply to everyone
• Python SDK and PHP SDK: manage policies from code