Access Filters

Access Filters provide row-level access control in SignalSmith. An access filter 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 Filters Work

When an access filter is active for a user (via their group membership), SignalSmith automatically appends the access filter’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
• Trait evaluation — Trait computation scoped to the access filter
• Sync execution — Only rows matching the access filter are synced to destinations

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

Use Cases

Creating an Access Filter

Via the UI

1. Navigate to Govern > Access Filters in the sidebar
2. Click Add Access Filter
3. Fill in the access filter configuration:

4. Click Save

Via the API

curl -X POST https://your-workspace.signalsmith.dev/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 filter 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 filter’s filter column, the access filter 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 filters. They help you group related access filters for easier management and determine how multiple access filters interact.

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

How Categories Affect Access Filter Combination

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

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

Example:

A group has:

• “EMEA” and “APAC” access filters in the Regional category
• “Marketing” access filter 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 Filters to Groups

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

Via the UI

1. Navigate to Govern > RBAC > Groups
2. Click on the group you want to modify
3. In the Access Filters section, click Add Access Filter
4. Select the access filter(s) to assign
5. Click Save

Via the API

curl -X PUT https://your-workspace.signalsmith.dev/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 filters, the access filters from all groups are merged:

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

Example:

• Group “EMEA Team” has access filter: region = 'EMEA'
• Group “APAC Team” has access filter: 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 filter 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 filters.

How Access Filters Are Applied

When a query is executed on behalf of a user:

1. SignalSmith resolves the user’s group memberships
2. All access filters assigned to those groups are collected
3. Access filters 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 filter:

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

After access filter (region = 'EMEA'):

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

After access filter (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 Filters

Editing an Access Filter

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

Disabling an Access Filter

You can disable an access filter without deleting it. A disabled access filter 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 Filter

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

Audit Trail

Access filter application is logged in the governance audit trail:

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

View the audit trail from Govern > Access Filters > Audit Log, or query via the API.

API Reference

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

Common Patterns

Next Steps

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