> ## 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.
# Source Access Rules
> Block specific sources or attributes within sources from individual audience and journey folders. Part of Zeotap's Access Rules governance model.
## 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](/articles/admin-customer/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
Navigate to **Sources** and open the specific source you want to configure an access rule for.
Select the **Access Rule** tab. If no rules exist yet, you'll see the **No Rules Configured** empty state.
Click **+ Add Folder Rule** and choose the audience and journey folders where the source (or specific attributes) should be blocked.
Choose **Select all** to block every attribute from the source in the selected folders, or pick individual attributes to restrict access more narrowly.
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.
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.
### Edit an existing rule
Navigate to **Sources**, open the source, and select the **Access Rule** tab.
Click **Edit Folder Rules** to add or remove folders, or adjust the attribute scope. Save when done.
### Delete a rule
Navigate to **Sources**, open the source, and select the **Access Rule** tab.
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.
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.