Access Policies

Access Policies provide row-level access control in Zeotap. An access policy defines a SQL filter condition that is automatically applied to all queries when a member of a specific group accesses data. This ensures that team members only see the data they are authorized to see — without requiring separate models or warehouse views.

How Access Policies Work

When an access policy is active for a user (via their group membership), Zeotap automatically appends the access policy’s filter condition to every query that runs on behalf of that user. This applies to:

• Model previews — SQL query results in the model editor
• Audience builder — Filter counts, estimation, and preview
• Computed attribute evaluation — Computed attribute evaluation scoped to the access policy
• Sync execution — Only rows matching the access policy are synced to destinations

The filtering is transparent and automatic. Users do not need to add WHERE clauses to their queries — the access policy condition is injected by the platform.

Use Cases

Creating an Access Policy

Via the UI

1. Navigate to Governance > Access Policies in the sidebar
2. Click Add Access Policy
3. Fill in the access policy configuration:

4. Click Save

Via the API

curl -X POST https://composable.zeotap.com/api/v1/subsets \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "EMEA Region Only",
    "description": "Limits data access to EMEA region customers",
    "category": "Regional",
    "filter_condition": "region = '\''EMEA'\''",
    "source_column": "region",
    "enabled": true
  }'

Filter Conditions

Access policy conditions are SQL WHERE clause fragments. They support standard SQL operators and syntax.

Simple Equality

region = 'EMEA'

IN Lists

country_code IN ('US', 'CA', 'MX')

Range Conditions

created_at >= '2024-01-01'

Combined Conditions

region = 'EMEA' AND customer_type = 'enterprise'

NULL Checks

partner_id IS NOT NULL

LIKE Patterns

email LIKE '%@mycompany.com'

Important Notes on Filter Conditions

• Filter conditions must reference columns that exist in the models being queried. If a model’s SQL output does not include the access policy’s filter column, the access policy cannot be applied and the query will fail with an error.
• Conditions are appended as AND clauses to existing queries. They do not replace existing WHERE conditions.
• Avoid complex subqueries in filter conditions. Simple equality, IN, range, and LIKE conditions perform best.
• String values must be properly quoted with single quotes within the condition.

Categories

Categories are organizational labels for access policies. They help you group related access policies for easier management and determine how multiple access policies interact.

Categories are free-form text — you define whatever categories make sense for your organization.

How Categories Affect Access Policy Combination

When a group has multiple access policies from the same category, they are combined with OR logic (the user sees data matching any of the access policies in that category).

When a group has access policies from different categories, the categories are combined with AND logic (the user sees data matching access policies from all categories).

Example:

A group has:

• “EMEA” and “APAC” access policies in the Regional category
• “Marketing” access policy in the Business Unit category

The effective filter is:

(region = 'EMEA' OR region = 'APAC')
AND (business_unit = 'marketing')

This means the user sees EMEA and APAC marketing data only.

Assigning Access Policies to Groups

Access policies are assigned to groups, not individual users. This makes management scalable — instead of assigning access policies to each user, you assign them to groups, and all members of the group inherit the access policy.

Via the UI

1. Navigate to Governance > RBAC > Groups
2. Click on the group you want to modify
3. In the Access Policies section, click Add Access Policy
4. Select the access policy/policies to assign
5. Click Save

Via the API

curl -X PUT https://composable.zeotap.com/api/v1/groups/{group_id} \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "subset_ids": ["sub_abc123", "sub_def456"]
  }'

Multiple Groups

When a user belongs to multiple groups with different access policies, the access policies from all groups are merged:

• Access policies within the same category (across groups) are combined with OR
• Access policies across different categories are combined with AND

Example:

• Group “EMEA Team” has access policy: region = 'EMEA'
• Group “APAC Team” has access policy: region = 'APAC'
• A user in both groups sees data where region = 'EMEA' OR region = 'APAC'

Role Exemptions

Users with the Owner or Admin role are exempt from access policy filtering by default. They can see all data regardless of group membership. This exemption can be overridden in workspace settings if you need admins to also be subject to access policies.

How Access Policies Are Applied

When a query is executed on behalf of a user:

1. Zeotap resolves the user’s group memberships
2. All access policies assigned to those groups are collected
3. Access policies are grouped by category and combined (OR within category, AND across categories)
4. The combined condition is appended as an AND clause to the query

Before access policy:

SELECT customer_id, email, region
FROM customers
WHERE lifetime_value > 100

After access policy (region = 'EMEA'):

SELECT customer_id, email, region
FROM customers
WHERE lifetime_value > 100
  AND (region = 'EMEA')

After access policy (two categories):

SELECT customer_id, email, region, business_unit
FROM customers
WHERE lifetime_value > 100
  AND (region = 'EMEA' OR region = 'APAC')
  AND (business_unit = 'marketing')

Managing Access Policies

Editing an Access Policy

Changes to an access policy’s condition take effect immediately. All subsequent queries from users in groups with that access policy will use the updated condition. Existing cached results are not retroactively filtered.

Disabling an Access Policy

You can disable an access policy without deleting it. A disabled access policy is not applied to any queries, even if it is still assigned to groups. This is useful for temporarily removing a restriction.

Deleting an Access Policy

Deleting an access policy removes it from all groups. Users who were restricted by the access policy will no longer have the filter applied. This action cannot be undone.

Audit Trail

Access policy application is logged in the governance audit trail:

• Access policy applied to query (with user ID, group ID, and access policy ID)
• Access policy condition used
• Query modified (original and filtered versions)

View the audit trail from Governance > Access Policies > Audit Log, or query via the API.

API Reference

# List all access policies
GET /api/v1/subsets
 
# Get a single access policy
GET /api/v1/subsets/{id}
 
# Create an access policy
POST /api/v1/subsets
 
# Update an access policy
PUT /api/v1/subsets/{id}
 
# Delete an access policy
DELETE /api/v1/subsets/{id}

Common Patterns

Next Steps

• Create groups to organize members for access policy assignment
• Set up RBAC roles to control who can create and manage access policies
• Configure destination policies for additional data flow controls