Role-Based Access Control (RBAC)

Zeotap uses role-based access control to manage who can access and modify resources within a workspace. The RBAC system provides three built-in roles plus custom workspace roles, 47 fine-grained permissions across 15 resource categories, and an additive permission model that makes it straightforward to reason about what any member can do.

How RBAC Works

Every workspace member is assigned exactly one role. That role determines which permissions the member has. Permissions are checked on every API request and UI action — if a member lacks the required permission, the action is denied.

Core Concepts

Concept	Description
Role	A named set of permissions assigned to a member. Zeotap includes three built-in roles (Owner, Admin, Member) and supports custom roles with any combination of permissions.
Permission	A specific action on a specific resource type (e.g., `sources.create`, `audiences.delete`).
Group	A collection of members. Groups can be assigned a role and/or granted direct permissions, which are merged with each member’s own role permissions. Groups can also be used for access filter assignment.
Access Filter	A row-level filter assigned to a group. When active, it restricts which data rows a member can see.

Additive Permission Model

Zeotap uses an additive permission model — permissions are granted, never denied. A member’s effective permissions come from the union of their direct role permissions, all group roles they belong to, and any direct permissions granted to those groups. There is no concept of “deny” rules or permission overrides.

This means:

If a role includes a permission, the member can perform that action
If a group the member belongs to has a role or direct permissions, those are added to the member’s effective permissions
There are no ways to selectively deny a permission that a role or group grants

Permission Evaluation

When a member performs an action (via the UI or API), Zeotap:

Identifies the member’s role
Collects permissions from the member’s role
Collects permissions from all groups the member belongs to (both group roles and direct group permissions)
Unions all permissions together
Checks if the required permission is present

This check happens in middleware on every API request, ensuring consistent enforcement regardless of how the action is initiated.

Built-in Roles

Zeotap provides three built-in roles that cover common organizational patterns:

Role	Target Users	Summary
Owner	Workspace creators, billing contacts	Full unrestricted access, including workspace deletion and ownership transfer
Admin	Team leads, senior operators	Full access to all resources and settings, except workspace deletion
Member	Analysts, marketers, individual contributors	Read/write access to operational resources; no access to infrastructure or governance settings

See Roles for a detailed permission comparison.

In addition to these built-in roles, workspace admins can create custom roles with any subset of permissions. See Roles for details.

Permission Categories

Permissions are organized into 15 resource categories:

Category	Permissions	Description
Sources	5	Manage warehouse connections
Models	4	Manage SQL models
Destinations	7	Manage destination connections
Syncs	5	Manage data syncs
Audiences	4	Manage audience segments
Traits	4	Manage computed traits
Identity Graphs	2	Manage identity resolution
Journeys	2	Manage multi-step journeys
Events	2	Manage event ingestion
Loaders	2	Manage loaders
Govern	2	Manage filters, access filters, groups
Insights	1	View analytics dashboards
Settings	2	Manage workspace settings
Agent	2	Manage AI agent sessions
Roles	2	Manage custom role definitions

Total: 47 permissions across 15 categories.

See Permissions for the complete reference table.

Groups

Groups organize members into logical teams. Groups serve two purposes:

Grant additional permissions — A group can be assigned a role or granted specific permissions directly. Members of the group inherit those permissions in addition to their own role’s permissions.
Control data visibility — Groups are the assignment target for access filters. When a group has access filters, its members’ queries are automatically filtered.

See Groups and Access Filters for details.

Quick Start

1. Understand the Default Roles

When a workspace is created, the creator is assigned the Owner role. New members invited to the workspace are assigned the role specified in the invitation.

2. Invite Members with Appropriate Roles

For most team members, start with the Member role. Promote to Admin when a member needs to manage infrastructure resources (sources, destinations) or governance settings.

3. Create Groups for Data Access

If different teams need to see different portions of data, create groups and assign access filters:

Create a group (e.g., “EMEA Team”)
Create an access filter (e.g., region = 'EMEA')
Assign the access filter to the group
Add members to the group

4. Set Up Destination Filters

If you need to control where data can flow, create destination filters to block, transform, or rate-limit syncs.

API Reference

# Members
GET    /api/v1/members
POST   /api/v1/members/invite
PUT    /api/v1/members/{id}
DELETE /api/v1/members/{id}
 
# Groups
GET    /api/v1/groups
POST   /api/v1/groups
PUT    /api/v1/groups/{id}
DELETE /api/v1/groups/{id}
 
# Group Membership
POST   /api/v1/groups/{id}/members
DELETE /api/v1/groups/{id}/members/{member_id}
 
# Custom Roles
GET    /api/v1/workspaces/{id}/roles
POST   /api/v1/workspaces/{id}/roles
PUT    /api/v1/workspaces/{id}/roles/{roleId}
DELETE /api/v1/workspaces/{id}/roles/{roleId}
 
# Group Permissions
GET    /api/v1/workspaces/{id}/groups/{groupId}/permissions
PUT    /api/v1/workspaces/{id}/groups/{groupId}/permissions

See the API Reference for full request/response schemas.

Pages in This Section

Roles — Built-in role definitions and permission comparison
Permissions — Complete permission reference (47 permissions, 15 categories)
Groups — Creating and managing groups
Managing Members — Inviting, modifying, and removing workspace members

Access Filters Roles