Folder and Destination Access

You can restrict a folder or a destination to named groups. Use it when a folder belongs to one team, such as “Finance audiences”, or when only one team should send to a destination, such as “only the CRM team may sync to Salesforce”.

This is different from an access policy:

The two live together under Governance → User Access Policies, on the Folders and Destinations tabs.

How It Works

Everything is open until you name a group. By default, anyone with the ordinary read permission (folders.read or destinations.read) can see every folder and destination. Nothing is restricted by default, and turning the feature on changes nothing for anyone.

Naming a group restricts the resource. Once a folder or destination names one or more groups, only members of those groups can reach it, each at the level its group was given (see Access Levels). If you name several groups, a member of any of them qualifies.

Removing the last group lifts the restriction. The resource goes back to being open to everyone with the read permission. The same happens if every group it names is deleted, so a restriction can never leave a resource that nobody can reach or repair.

Access Levels

Each group you name has one of two levels. A group you do not name has no access.

A few rules decide which level applies:

• The most generous group wins. Someone in a Can view group and a Can edit group on the same folder can edit.
• A subfolder can narrow access, never widen it. If a folder gives a team Can view, the team has at most Can view in every subfolder, even if a subfolder names the team at Can edit. A subfolder can narrow a Can edit team to Can view.
• Both sides must allow it. An audience sync is editable only by someone who can edit both the folder its audience is in and the destination it sends to. An A/B test is editable only by someone who can edit both its own folder and its audience’s folder.
• Levels never add to a role. A level limits what a person’s role already allows; it never grants more. A Member at Can edit still cannot delete a folder, because only Admins can.

Someone with Can view who tries to change something gets a permission error that names the folder or destination. Someone with no access gets not found, as if it did not exist.

Using something you can view as an input is allowed: you can use an audience you can view as a condition in your own audience, or reference it from a canvas. Sending to a destination you can only view is not allowed.

What a Restriction Covers

A restriction applies everywhere. For people outside the named groups, a restricted resource is absent from every list, picker and builder, and from the API. Opening it directly, by link or by ID, returns not found rather than a permission error, so the response does not even confirm that it exists.

Folders

Restricting a folder restricts everything in it:

• The folder itself, which disappears from the folder tree. People outside the named groups cannot open, rename, move or delete it, or move anything into it.
• Every folder below it. If you cannot reach a folder, you cannot reach the folders inside it either.
• Every audience, orchestration and A/B test filed in it, or in any folder below it. These disappear from their own lists (including All on the Audiences page) and cannot be opened, edited, run, duplicated or deleted.
• What depends on those audiences. The audience syncs of a hidden audience, and any A/B test that splits it, are hidden too, wherever the A/B test itself is filed. A hidden audience cannot be used as a condition in another audience or in an orchestration’s criteria.
• Audience canvases that publish into it. A canvas is treated as being where its audiences are published, so a canvas whose target folder is restricted is hidden too. A canvas cannot reference a hidden audience, and a canvas’s list of published audiences leaves out any that were moved somewhere the viewer cannot reach.

A subfolder can be restricted to a narrower set of groups than its parent, for example a “Finance / Payroll” folder kept to a subset of the finance team. Naming a wider set on a subfolder grants nothing extra: people the parent excludes still cannot reach it. The Folders tab shows each folder’s full path, so you can tell when you are restricting a whole subtree.

Destinations

Restricting a destination restricts what sends to it:

• The destination disappears from the Destinations page and from the destination pickers in the sync, audience sync and orchestration builders.
• Every sync and audience sync that sends to it disappears for people outside the named groups, together with its run history. They cannot open, edit, run or delete it.
• Saving a sync, an audience sync or an orchestration step that names the destination by ID is refused.

Scheduled work keeps running

Restrictions decide who can see and act on a resource; they never stop work that is already scheduled. A sync or an orchestration on a schedule keeps running on that schedule, even when the person who set it up is outside the groups a folder or destination now names. To stop one, a member of a named group pauses or edits it.

Managing Restrictions

Via the UI

1. Navigate to Governance → User Access Policies in the sidebar
2. Open the Folders or Destinations tab
3. By default the table lists only the restricted folders or destinations. Click Show all folders or Show all destinations to find the one you want to restrict.
4. In the Groups that may reach it column, click + Restrict and add the groups that should keep access. A new group starts at Can edit.
5. To make a group view-only, choose Can view in the group’s chip. Remove a group with the × on its chip, or remove every group to lift the restriction.

Changes save immediately.

The groups you can name are the groups that have a grant on this workspace; if none do, the picker reads “No groups reach this workspace”. To restrict a resource to a team, first create the group and grant it access to the workspace.

Who can change restrictions. Editing a folder’s groups requires folders.write, and editing a destination’s groups requires destinations.write, the same permissions used to edit the resources themselves. People with those permissions see every restricted resource on these tabs, including ones restricted to groups they are not in, so they can always widen a restriction again.

A destination shared into your workspace from another workspace does not appear here. Its access is configured by the workspace that owns it.

Via the API

Read a resource’s access list:

curl "$API_BASE_URL/api/v1/workspaces/$WORKSPACE_ID/destinations/$DESTINATION_ID/groups" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "X-Workspace-ID: $WORKSPACE_ID"

Set it. The request states the complete list of groups with their levels, and replaces whatever was there before:

curl -X PUT "$API_BASE_URL/api/v1/workspaces/$WORKSPACE_ID/destinations/$DESTINATION_ID/groups" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "X-Workspace-ID: $WORKSPACE_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "groups": [
      { "group_id": "<crm-team-group-id>", "access_level": "edit" },
      { "group_id": "<analysts-group-id>", "access_level": "view" }
    ]
  }'

The response is the resulting access list:

{
  "groups": [
    { "group_id": "<crm-team-group-id>", "group_name": "CRM team", "access_level": "edit" },
    { "group_id": "<analysts-group-id>", "group_name": "Analysts", "access_level": "view" }
  ]
}

Folders use the same shape:

The two workspace-wide reads return one entry per restricted resource (resource_id, name, groups), including resources restricted to groups the caller is not in.

Common Setups

Next Steps

• Create groups for the teams you want to restrict to
• Set up access policies to restrict which data rows a group sees
• Configure destination policies to restrict which audiences may sync to a destination
• Folders to organize audiences, orchestrations and A/B tests