Folder Access Policies
A folder access policy is a filter you attach to a top-level folder. Every audience and orchestration filed in that folder, or in any folder below it, only ever includes the records that match the filter. Use it when everything in a folder has to stay inside one boundary, for example “everything in the Italy folder is Italian customers only”.
This is different from the two other access controls:
| Follows | Controls | Example | |
|---|---|---|---|
| User access policy | The person | Which rows a group’s members see | The EMEA team sees only region = 'EMEA' customers, wherever they work |
| Folder and destination access | The folder | Whether a folder is there at all for a person | Only the Finance group sees the Finance folder |
| Folder access policy | Where the item is filed | Which rows an audience or orchestration includes, for everyone | Every audience in Italy contains only country = 'IT' |
Folder access policies live under Governance → Folder Access Policies.
How It Works
A policy is a filter on your parent model. You build it with the same filter builder you use for audiences.
You attach it to top-level folders. It then applies to everything filed in those folders and in every folder below them. A folder can carry at most one policy, so an item is never under two at once.
It applies for everyone. An estimate, a preview, a manual or scheduled sync and an orchestration run all apply the same filter, whoever started them. It is combined with the item’s own conditions using AND, and with any user access policy the person has.
Moving an item changes which policy applies. An audience moved into a policy folder takes that folder’s policy; moved out, it no longer has one. Its next estimate, sync or run reflects the move.
Moving an audience out of a folder that has a policy widens it. Its next sync sends every record its own conditions match, including records the policy used to exclude. Every move is recorded in the audit log.
Audiences
An audience under a policy includes only records that match both its own conditions and the policy. Its syncs follow the audience: they apply the policy of the folder the audience is in, so there is nothing to configure on a sync.
Orchestrations
An orchestration under a policy only admits people who match the policy. Anyone already inside who stops matching leaves at the next run, including:
- people who entered before the policy was attached,
- people in an orchestration moved into a policy folder,
- people whose data changed so they no longer match.
A person whose value for a policy column is empty does not match, so they leave too.
What a policy cannot be built on
A policy is written against one parent model. If an item in a policy folder is built on a different parent model, its estimates, syncs and runs fail with a message naming the policy and the folder. The policy is never skipped, because skipping it would let the item include records the folder is meant to exclude.
Separate Folders for Audiences and Orchestrations
Audiences and orchestrations keep separate folder trees. A folder belongs to one or the other, so you can have an Italy folder for audiences and another Italy folder for orchestrations, each with its own policy. A/B tests and audience syncs use the audiences tree.
When this was introduced, every existing folder stayed with audiences and a copy of the whole tree was created for orchestrations, including each folder’s group access list. Both lists look as they did. You can delete any orchestration folders you do not need.
Managing Policies
Owners and Admins can create, edit, attach and delete policies (folders.write). Everyone who can read folders can see them.
- Create: name the policy, choose the parent model, build the filter, and select the top-level folders it applies to. A folder already used by another policy is shown but cannot be selected.
- Edit: you can change the name, the description, the filter and the folders. The parent model is fixed, because the filter is built from its columns.
- Delete: the confirmation states how many audiences and orchestrations lose the filter.
A policy’s page shows how many audiences and orchestrations it currently applies to. An audience or orchestration under a policy shows the policy and the folder it comes from.
Folders that carry a policy
- Moving a top-level folder that carries a policy under another folder is refused. Detach the policy first.
- Deleting a top-level folder that carries a policy first states how many items lose the filter.
Not Covered Yet
A policy is not yet applied:
- when an audience is used as a condition inside another audience or an orchestration,
- to the streaming membership of realtime audiences,
- to audience canvas estimates before publishing.
API
See Folder access policies in the API reference.