This section explains how an admin:

structures data into domains and subdomains
assigns users and permissions
controls access to assets and monitors

🚧
Users assigned the Admin system role have full access to all features and data in Sifflet. They can view and manage all domains, assets, monitors, and platform settings without needing explicit domain assignment.
We recommend limiting this role to a small number of trusted users. For most users, the System Viewer role is sufficient and provides safer, more controlled access.

Step 1 — Create a domain

An admin first creates a domain, which represents a subset of all available data.

Example

An admin selects: 10 tables related to finance. These assets now belong to the Finance domain.

Step 2 — Create subdomains (optional)

To further organize data, a domain can be divided into subdomains.

Example

Finance domain is split into: Finance America and Finance Europe

Why use subdomains

organize data within a domain
reflect organizational structure
improve navigation

Step 3 — Create a user

The admin creates a new user.

Step 4 — Assign a system role

The admin assigns a system role to the user.

Examples of system roles

Admin
System Editor
System Viewer

System roles define platform capabilities only and do not grant access to data. The only exception is the Admin role, which automatically has full access to all domains, assets, and monitors.

Recommendation

Assign System Viewer by default unless higher privileges are required.

Step 5 — Assign domain (or subdomain) access and role

The admin grants the user access to a domain or subdomain and defines what they can do within it.

This step determines:

where the user has access (domain or subdomain)
what they can do (domain role)

Two ways to assign access:

Option 1 — Direct assignment : Assign the user directly to a domain or subdomain with a role.

Example:

User A→ Finance domain → Role Editor

Option 2 — Team-based assignment (recommended)

Add the user to a team
Assign the team to a domain or subdomain with a role

Example:

Team: Finance Team
Domain: Finance
Role: Viewer

All users in the team inherit this access.

Domain roles

Domain roles define what the user can do within a domain. Common roles include:

Viewer (read-only)
Editor (modify catalog and monitors)
Catalog Editor (manage documentation and catalog)
Monitor Responder (handle incidents and alerts)

ℹ️
Access is defined at the domain level and applies to all assets within that domain. Permissions are consistent across all assets in the same domain.

Examples

Data analyst

System role: System Viewer
Domain role: Viewer (Marketing)

Can:

view marketing assets and monitors

Cannot:

edit or access other domains

Data engineer

System role: System Editor
Domain roles:
- Finance → Editor
- Marketing → Viewer

Can:

edit finance assets and monitors
view marketing data

Data quality manager

System role: Viewer
Domain role: Monitor Responder

Can:

respond to incidents
investigate alerts

Advanced case — same asset across domains or subdomains

Scenario

An asset belongs to multiple domains or subdomains.

Example:

Asset: finance_report_table
Domain A → Finance (Editor access)
Domain B → Reporting (Viewer access)

User:

Editor in Domain A
Viewer in Domain B

Behavior

Access depends on the domain view:

From Domain A → user can edit
From Domain B → user can only view

Key takeaway

Each user in Sifflet has:

one system role
one or more domain roles

System roles define what a user can configure at the platform level (e.g. users, domains, integrations).

Domain roles define what data a user can access and what actions they can perform within that data.

Best practices

structure domains by business area
use teams instead of individual permissions
keep admin roles limited
design domains for scalability (use dynamic domains when possible)

ℹ️
Access tokens follow the same permission model as users, based on their level (system or domain).