Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.zeotap.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

Source Access Rules let admins control which data sources — and optionally which specific attributes within those sources — are available when building audiences or journeys in a given folder. This is useful when you have sources that contain a mix of safe and sensitive data. Rather than making the entire source off-limits, you can make it broadly available but block only the sensitive fields in contexts where they shouldn’t be used. For the broader governance model — including how Source Access Rules relate to Folder Access Control and Mandatory Templates — see Access Rules.
Composable Sources. The Join Key in sources tagged as Customer Parent Model cannot be restricted in any folder. This is because it is the foundation that enables profile unification — restricting it would break identity resolution across the org.

​
When to use Source Access Rules

Block sensitive attributes from specific teams. Your CRM source contains email, transaction history, loyalty tier, and national ID. Your marketing teams need email and transactions to build campaign audiences. They do not need national ID. You can block the national ID attribute from the marketing folders while keeping the rest of the source fully accessible. Restrict an entire source to specific contexts. You have a source containing medical or financial data that should only be accessible to a compliance-approved folder. You can block the entire source from all other folders, ensuring it only appears in the right context. Enforce data minimisation. Different teams should work with the minimum data necessary for their use case. A growth marketing team running acquisition campaigns doesn’t need loyalty or retention attributes. Blocking those attributes from the acquisition folder keeps the data environment clean and reduces the risk of misuse. Meet regional data requirements. Certain attributes may be permissible in one market but restricted in another. You can apply different rules to region-specific folders — for example, blocking a sensitive field from your Germany marketing folder while keeping it accessible in other markets.

​
How Source Access Rules work

​
Default state

By default, every source — both new and existing — is available across all folders. No restrictions are applied unless an admin explicitly configures them.
Access Rules cannot be applied to Archive folders.

​
Attribute-level control

Admins can either select all attributes from the source or select specific attributes within it.
  • Only the explicitly selected attributes are blocked in the targeted folders.
  • All other attributes from that source remain fully accessible in those folders.
  • For any new folder created after the rule is set, the source is fully accessible — including the otherwise blocked attributes. The new folder must be explicitly added to the rule for attribute restrictions to apply.
Behaviour for new attribute mappings added after a rule is set:
  • Any new attribute mapping added to the source after the rule is set is accessible in all folders by default. It is not automatically blocked unless explicitly added to the rule.
Unified attributes. Zeotap unifies attributes across sources. If two ingested sources both contribute to a unified attribute (e.g., Email) and one source is blocked in a folder, the unified attribute becomes unavailable in that folder — even though the second source is still active. Admins will see a prominent warning before confirming any configuration that has this effect.

​
Configure Source Access Rules

​
Create a Source Access Rule

1

Open the source

Navigate to Sources and open the specific source you want to configure an access rule for.
2

Open the Access Rule tab

Select the Access Rule tab. If no rules exist yet, you’ll see the No Rules Configured empty state.
Source Access Rule tab showing the No Rules Configured empty state.
3

Add a folder rule

Click + Add Folder Rule and choose the audience and journey folders where the source (or specific attributes) should be blocked.
Select Folders dialog with audience and journey tabs and a list of folders.
4

Select the attributes to block

Choose Select all to block every attribute from the source in the selected folders, or pick individual attributes to restrict access more narrowly.
Configure field access dialog with an attribute checklist and a cross-source impact note.
5

Review the impact warning

If the source contributes to any unified attributes, you’ll see a confirmation dialog calling out the cross-source impact before the rule is saved.
Do You Want To Save dialog with a cross-source impact warning.
6

Save the rule

Click Confirm & Save. The rule appears on the Access Rule tab, listing the audience and journey folders it applies to, along with the count of blocked attributes per folder.
Source Access Rule tab with a saved rule listing three audience folders and two journey folders.

​
Edit an existing rule

1

Open the source's Access Rule tab

Navigate to Sources, open the source, and select the Access Rule tab.
2

Edit folder rules

Click Edit Folder Rules to add or remove folders, or adjust the attribute scope. Save when done.

​
Delete a rule

1

Open the source's Access Rule tab

Navigate to Sources, open the source, and select the Access Rule tab.
2

Clear all or remove specific folders

Click Clear All Rules to remove every folder rule on the source. To remove specific folders only, click Edit Folder Rules and use the cross icon next to the folders you want to remove.

​
What users see when a source is restricted

​
In the Audience Builder

Blocked attributes are not available for selection — even if the source itself is otherwise accessible. Templates that use restricted attributes cannot be used either. Users also cannot send the restricted attributes to any destinations within the folder.
Users can still use calculated attributes that reference blocked attributes within these folders.
Existing audiences affected by a new rule: Existing audiences continue running without interruption. However, any audience using a now-restricted attribute is flagged with a warning status on both the folder and the audience definition page.
Audiences list showing a row with a warning icon and tooltip about restricted mappings.
Audience criteria builder showing the restricted-attribute warning banner with action guidance.
Users cannot publish changes to a flagged audience until the conflict is resolved — either by removing the restricted attribute from the audience definition, or by an admin updating the rule.

​
In the Journey Builder

Blocked attributes are not available for selection — even if the source itself is otherwise accessible. Templates that use restricted attributes cannot be used either. Users also cannot send the restricted attributes to any destinations within the folder.
Users can still use real-time calculated attributes that reference blocked attributes within these folders.
Existing journeys affected by a new rule: Existing journeys continue running without interruption. However, any journey using a now-restricted attribute is flagged with a warning status on both the folder and the journey definition page. As with audiences, users cannot publish changes to a flagged journey until the conflict is resolved.
Last modified on May 12, 2026