Row policies

Show each person only their rows of a dataset, using user attributes or groups, everywhere that dataset is used.

A row policy limits which rows of a dataset each person sees, such as only their own regions. One dataset and one report can then serve everyone, with each person seeing their part.

How a policy works

A policy compares one field in each row with something about the person asking: their values for a user attribute, or the names of their groups. Halo Data reads it back as a sentence:

People see rows where Region is one of their regions.

You build policies from menus, so there's no expression to write. In a dataset's definition, that one is stored like this, where regions is the attribute Halo Data lists as {{user.regions}}:

{
  "id": "by-region",
  "field": "region",
  "op": "in",
  "value": { "kind": "attribute", "attribute": "regions" },
  "exempt": { "roles": ["owner", "admin"] }
}

Set up user attributes

Skip this if you'll compare with group names. Otherwise, you need the Manage members permission.

1. Open Settings, Members. Under User attributes, choose New attribute.

2. Give it a Name, such as Regions, and a Key, such as regions. The key is lowercase letters, numbers and underscores, starting with a letter. It can't change later, since policies name it. email, groups, id, name and role are reserved.

3. Open each member's page and set their values under User attributes. A member can hold several: North and East, say.

Every change to attributes is in the audit log.

Add a policy

1. Open the dataset's Access tab and choose Add policy.

2. Field: the field each row is checked by. It needs a value per row, so a column works, and an aggregated measure doesn't.

3. Rows where it: is one of or isn't one of.

4. Their: a user attribute, or Groups, by name.

5. Doesn't apply to: roles and groups that see every row. New policies leave out Owners and Admins. Clear this to filter everyone.

6. Choose Save new version.

Values compare exactly, as the field's type, so North doesn't match north. A dataset can have up to 50 policies, and each one that applies to someone must hold.

Check it

Under Preview as a member on the Access tab, pick someone and choose Explore as them. It shows which policies apply and their values, then opens the explorer with their rows. If policies limit what you see, the preview is limited the same way, and background exports stay off while you preview.

Previews use the saved version, so save first.

Where policies apply

Everywhere the dataset is queried: rows, counts, totals and exports, on every surface.

Saved results are never shared between people who may see different rows.

An edition's figures are what it published, so a later policy can't reach them. Saving a policy change on a dataset that published editions read asks whether to keep them or withdraw them. See When a dataset changes under an edition.

Policies fail closed

When Halo can't tell what someone should see, it shows nothing rather than everything.

• Someone with no values for the attribute sees no rows. The policy's summary in Halo Data says so.

• Rows where the field is empty are kept by neither is one of nor isn't one of.

• A policy Halo can't apply, such as one on a field that's gone, fails the query for everyone with an error, rather than being skipped.

If a member reports an empty chart, preview as them first. Missing values are the usual cause.

What policies don't cover

Policies filter a dataset, not the tables behind it. People who can build datasets on the same connection can still read those tables, so keep dataset building to people who may see every row. A member's role and sharing still decide whether they can open the dataset at all; see Roles and permissions.

When a save moves charts to a renamed field's replacement, policies aren't moved with them. Update any policy on that field yourself.