Role-Based Access Control (RBAC)

SignalSmith uses role-based access control to manage who can access and modify resources within a workspace. The RBAC system provides three built-in roles, 42 fine-grained permissions across 14 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. Every member has exactly one role.
Permission	A specific action on a specific resource type (e.g., `sources.create`, `audiences.delete`).
Group	A collection of members used for access filter assignment. Groups do not grant additional permissions — they control data visibility via access filters.
Access Filter	A row-level filter assigned to a group. When active, it restricts which data rows a member can see.

Additive Permission Model

SignalSmith uses an additive permission model — permissions are granted, never denied. A member’s effective permissions come entirely from their assigned role. 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 role does not include a permission, the member cannot perform that action
There are no ways to selectively deny a permission that a role grants

Permission Evaluation

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

Identifies the member’s role
Looks up the permissions associated with that role
Checks if the required permission for the action is present
Allows or denies the action accordingly

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

Built-in Roles

SignalSmith 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.

Permission Categories

Permissions are organized into 14 resource categories:

Category	Permissions	Description
Sources	5	Manage warehouse connections
Models	4	Manage SQL models
Destinations	5	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

Total: 42 permissions across 14 categories.

See Permissions for the complete reference table.

Groups and Access Filters

While roles control what actions a member can perform, groups and access filters control what data a member can see.

Groups organize members into logical teams (e.g., “EMEA Marketing”, “Partner Support”)
Access Filters are SQL filter conditions assigned to groups (e.g., region = 'EMEA')
When a member belongs to a group with an access filter, all their queries are automatically filtered

Groups do not grant additional permissions. They are purely a mechanism for managing data visibility through access filters.

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}

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 (42 permissions, 14 categories)
Groups — Creating and managing groups
Managing Members — Inviting, modifying, and removing workspace members

Access Filters Roles