RBAC - DQLabs PRIZM

Overview

The Prizm platform utilizes a flexible Role-Based Access Control (RBAC) system with optional Attribute-Based Access Control (ABAC) filters. This model provides granular control over resource access while remaining operationally manageable for enterprise administrators. The RBAC system enables organizations to align access controls with their specific organizational structure and security requirements through custom roles, hierarchical inheritance, and tag-based filtering.

Core Principles

Principle	Description
Resource Independence	Domains, Products, Apps, and other resources are independently secured
Hierarchical Inheritance	Permissions cascade based on resource relationships
Role Precedence	Higher-priority roles take precedence in access decisions
Tag-Based Filtering	Additional constraints based on data classification tags
RBAC + ABAC	Role-Based Access Control with optional Attribute-Based filters (tags, ownership, sensitivity)
Highest-Role-Wins	When multiple roles apply, the highest permission level takes precedence
Loosely Coupled Resources	Domains, Products, Apps, Tags, and Connections are independently assignable
Custom Roles	Administrators can define tailored roles for advanced use cases

Key Entities

Entity	Description
Member	People or agents interacting with the system, authenticated via SSO or direct login
Groups	Logical collections of users (e.g., Marketing, Engineering) that map to SSO groups
Roles	Abstract responsibilities (Owner, Steward, Member, Admin) with defined permission sets
Permissions	Atomic actions (read, write, approve, manage security) defining what operations are allowed
Assignments	Mappings of roles to users/groups for specific resources with optional constraints
Resources	Domain, Product, App, Connection — loosely linked with Tags as optional constraints

Access

The Prizm platform uses a flexible Role-Based Access Control (RBAC) system with optional Attribute-Based Access Control (ABAC) tag filters. The Access module is the central hub for managing all of this — Members, Groups, Roles, Permission Sets, and Audiences are all managed here.

The Access dashboard surfaces five key counters at a glance:

Entity	Count	Purpose
Member	28	Individual users in the organization
Group	2	Collections of users sharing a role assignment
Role	4	Named permission profiles (Owner, Steward, User, custom)
Permission Set	4	Sets of toggled permissions (420 total defined)
Audience	2–3	Notification channel subscriber groups

Members

The Member tab lists every user in the organization along with their assigned role, active status, MFA enrollment, and SSO status.

Member Fields

Column	Description
Email	User’s login email address
First Name / Last Name	Display name (populated from SSO or manually)
Role	The role assigned to this user — Owner, Steward, User, or a custom role
Status	Toggle — active (dark) or inactive (grey)
MFA	Whether multi-factor authentication is enrolled for this user
SSO	Whether this user authenticates via Single Sign-On
Action	Copy assignment, view details, or delete the member

Adding a Member

Click the ⊕ icon in the top-right of the Member section. You will be prompted to enter an email address and select a role. On first login, the user receives an invite email.

The Owner role cannot be deleted or downgraded by anyone other than another Owner. At least one active Owner must exist in every organization.

Groups

Groups let you assign a single role to a collection of users. When a user’s group membership changes in the identity provider, their Prizm permissions update automatically on next login.

Group Fields

Column	Description
Name	Unique group name, editable inline
Description	Optional free-text description of the group’s purpose
Role	The role applied to all members of this group
Users	Avatar stack showing assigned users; click ⊕ to add more
Status	Active / inactive toggle for the entire group
Action	Delete the group

Group vs. Direct Assignment

Scenario	Recommendation
Stable team with a shared role (e.g., all Marketing → Steward)	Use a Group
Individual exception or temporary elevated access	Use a direct Member assignment
IdP-synced department structure	Use Groups mapped to SSO groups

When a user has both a direct role assignment and a group role assignment, the highest-priority role wins.

Roles

Roles define a named permission profile. Prizm ships with three built-in roles and supports custom roles created by administrators.

Standard Roles

Role Definitions

Role	Priority	Permissions Summary
User	1	Read-only for non-sensitive assets; can request access
Steward	2	Limited to assigned resources; can edit metrics/sources, but not security
Owner	3	Full control over owned domains, applications, and products; can manage semantics, metrics, data sources, security, and approve all changes.
Custom	5+	Tailored by admins (e.g., Data Scientist, ViewerPII) with specific permission filters

Custom Roles

Custom roles (e.g., cx_role) are created by administrators and can be tailored with any combination of permissions from the Permission Set. Custom roles are assigned a priority of 5+ and appear with both edit and delete actions in the Role table. To create a custom role:

Click ⊕ in the Role section
Enter a name and optional description
Select the Permission Set to associate with this role
Save — the role is immediately available for assignment to members and groups

Deleting a custom role immediately removes it from all members and groups currently assigned to it. Users will fall back to their next highest active role.

Permission Sets

A Permission Set defines exactly which actions are enabled for each role. The Permission Set view shows a toggle matrix — rows are permission types and columns are the available roles (Admin, Editor, Viewer, and any custom sets).

Reading the Matrix

Dark toggle (●) — permission is enabled for this role
Light toggle (○) — permission is disabled for this role
Each row is a TYPE + ACCESS combination (e.g., ACCESS › Approve, ALERT › Create)

Default Permission Set Coverage

The four built-in permission sets cover 420 permissions across 25 resource types. The table below summarizes what each role can do by default.

Permission Set	Typical Role	Default Capabilities
Admin	Owner	All permissions across all types enabled
Editor	Steward	Create, edit, view; limited approve; no delete of core entities
Viewer	User	View only across most types; can request access

Permission Set Matrix

Each Permission Set (Admin, Owner, Steward, Member, Custom) can be assigned with one to many permissions sets and its relevant access.

Permission	Admin : 4	Owner : 3	Steward : 2	Member : 1	Custom : 5
Create/Edit Security	✅	❌	❌	❌	Configurable
Create/Edit Semantics	✅	✅	❌	❌	Configurable
Create/Edit Sources	✅	✅	✅	❌	Configurable
Create/Edit Metrics / Queries	✅	✅	✅	❌	Configurable
Approve Resources	✅	✅	✅	❌	Configurable
View / Request Access	✅	✅	✅	✅	Configurable

Permission Type Reference

The following table lists every permission type and the actions available for each. This set of permission sets are grouped under a particular permission and that can be tied to a resource assignment.

Resource Type	Available Actions
Access	approve, create, delete, edit, view
Actions	create, delete, edit, view
Alert	approve, create, delete, edit, view
Analytics	approve, create, delete, edit, view
Application	approve, create, delete, edit, view
Asset	approve, create, delete, edit, view
Command Center – Jobs	view
Command Center – Logs	view
Command Center – Schedule	approve, edit, view
Command Center – Utility Import/Export	edit, view
Dimension	create, delete, edit, view
Domain	approve, create, delete, edit, view
Exception	edit, view
Field	create, delete, edit, view
Issue	approve, create, delete, edit, view
Metric and Queries	approve, create, delete, edit, view
Organization – Integration	approve, create, delete, edit, view
Organization – Overview	approve, create, delete, edit, view
Organization – SAML/SSO	edit, view
Product	approve, create, delete, edit, view
Setting	approve, create, delete, edit, view
Source	approve, create, delete, edit, run, schedule, view
Steward	approve, create, delete, edit, view
Tag	approve, create, delete, edit, view
Term	approve, create, delete, edit, view

Source is the only resource type with run and schedule actions in addition to the standard CRUD set. These allow a role to trigger data source syncs and set up recurring ingestion schedules independently of edit rights.

What Each Action Means

Every resource type in the table above is governed by the same five actions (plus a handful of resource-specific ones). In general:

Action	Meaning
View	See the resource type’s list/dashboard and open its detail pages. Read-only — no changes can be made.
Create	Add a brand-new record of that resource type (a new Member, Alert rule, Domain, Term, and so on).
Edit	Modify an existing record’s fields, configuration, or metadata.
Delete	Permanently remove an existing record. This cannot be undone.
Approve	Sign off a record that is sitting in a pending/draft governance state, moving it into an Approved / Active state. Until something is approved it typically stays Pending or Ready for Review — visible, but not yet counted toward scores, alerts, or the published catalog.

Approve is Prizm’s governance sign-off step. It shows up wherever an object goes through a Pending → Ready for Review → Approved lifecycle before other users, alerts, or scores can rely on it. A user without the Approve permission for a given resource type can still create or edit that resource, but their changes stay pending until someone who does have Approve signs off.

Permission Actions by Resource Type

The table below spells out what each action does for every resource type — this is the detail behind the summary table above.

Resource Type	Action	What it does
Access	View	See the Member, Group, Role, and Permission Set tabs under Access.
Access	Create	Invite a Member, or create a Group, custom Role, or Permission Set.
Access	Edit	Change a Member’s role, a Group’s members/role, or toggle entries in a Permission Set.
Access	Delete	Remove a Member, Group, custom Role, or Permission Set.
Access	Approve	Approve a pending access or role-elevation request raised through Prizm’s request-access flow (the same flow the User role uses to “request access” to a resource it can’t yet see).
Actions	View	See workflow actions configured under Action.
Actions	Create	Build a new workflow action.
Actions	Edit	Modify an action’s trigger or logic.
Actions	Delete	Remove a workflow action.
Alert	View	See the Alert dashboard and alert list.
Alert	Create	Configure a new alert rule or threshold.
Alert	Edit	Modify an alert’s threshold, priority, or routing.
Alert	Delete	Remove an alert or alert configuration.
Alert	Approve	Mark a flagged alert as reviewed (updates its Marked As status on the Alert list) so it’s recorded as triaged rather than left open.
Analytics	View	Open the Catalog, Observability, Quality, and Exception dashboards under Analytics, plus any dashboard/view another user has shared.
Analytics	Create	Build and save a new custom Analytics dashboard or view (the Save as view action on any Analytics page).
Analytics	Edit	Modify an existing saved Analytics dashboard/view — its filters, widgets, or layout.
Analytics	Delete	Remove a saved Analytics dashboard/view.
Analytics	Approve	See the callout below — this is the one most teams ask about.
Application	View	See registered Applications.
Application	Create	Register a new Application.
Application	Edit	Modify an Application’s configuration or ownership.
Application	Delete	Remove an Application.
Application	Approve	Approve a newly registered or edited Application before it counts as active/verified.
Asset	View	See asset catalog pages.
Asset	Preview	View data samples/previews for an asset without needing full Edit rights.
Asset	Create	Manually register a new asset.
Asset	Edit	Modify an asset’s metadata, description, owners, or classification.
Asset	Delete	Remove an asset from the catalog.
Asset	Approve	Approve pending AI-generated metadata recommendations for an asset (the Approve Recommendations control on the asset header), advancing its status badge (Pending → Ready for Review → Verified).
Command Center – Jobs	View	See job run history in Command Center.
Command Center – Logs	View	See system/job logs in Command Center.
Command Center – Schedule	View	See configured sync/job schedules.
Command Center – Schedule	Edit	Change a schedule’s frequency or timing.
Command Center – Schedule	Approve	Approve a proposed schedule change before it takes effect.
Command Center – Utility Import/Export	View	See import/export utility jobs.
Command Center – Utility Import/Export	Edit	Configure or run an import/export utility job.
Dimension	View	See data quality dimensions (Accuracy, Completeness, Timeliness, etc.).
Dimension	Create	Add a new dimension.
Dimension	Edit	Modify a dimension’s definition.
Dimension	Delete	Remove a dimension.
Domain	View	See Domains.
Domain	Create	Create a new Domain.
Domain	Edit	Modify a Domain’s ownership or classification.
Domain	Delete	Remove a Domain.
Domain	Approve	Approve a newly proposed Domain, or an AI-recommended domain assignment, before it becomes an active classification.
Exception	View	See exception records and the Exception dashboard.
Exception	Edit	Update an exception’s status (e.g., mark In Progress, Resolved, Rejected).
Field	View	See attribute/column-level field definitions.
Field	Create	Add a new field-level definition.
Field	Edit	Modify a field’s metadata.
Field	Delete	Remove a field-level definition.
Issue	View	See Issues.
Issue	Create	Open a new Issue.
Issue	Edit	Update an Issue’s details or assignment.
Issue	Delete	Remove an Issue.
Issue	Approve	Approve an Issue’s resolution, moving it from Ready for Review to Resolved.
Metric and Queries	View	See metrics and query performance metrics.
Metric and Queries	Create	Create a new metric or query-based check.
Metric and Queries	Edit	Modify a metric’s logic or threshold.
Metric and Queries	Delete	Remove a metric or query.
Metric and Queries	Exception	Create/manage exceptions raised against a metric’s violations.
Metric and Queries	Approve	Approve a metric so its status moves from Pending/Ready for Review to Approved. A metric that isn’t yet approved defaults to Inactive — it won’t run, alert, or contribute to scores.
Organization – Integration	View	See configured integrations (Alation, Purview, etc.).
Organization – Integration	Create	Add a new integration.
Organization – Integration	Edit	Modify an integration’s settings.
Organization – Integration	Delete	Remove an integration.
Organization – Integration	Approve	Approve an integration configuration change before it goes live.
Organization – Overview	View	See the Organization Overview page.
Organization – Overview	Create / Edit / Delete / Approve	Manage and sign off changes to the organization’s profile-level settings.
Organization – SAML/SSO	View	See SSO/SAML configuration.
Organization – SAML/SSO	Edit	Update SSO/SAML settings (Entity ID, ACS URL, SCIM URL, federation file).
Product	View	See Data Products.
Product	Create	Create a new Data Product.
Product	Edit	Modify a Data Product’s bundled assets, metrics, or documentation.
Product	Delete	Remove a Data Product.
Product	Approve	Approve a Data Product before it’s published for consumers.
Setting	View	See platform Settings pages.
Setting	Create / Edit / Delete	Manage entries under Settings.
Setting	Approve	Approve a settings change before it applies.
Source	View	See connected data Sources.
Source	Create	Connect a new Source.
Source	Edit	Modify a Source’s connection configuration.
Source	Delete	Disconnect/remove a Source.
Source	Run	Manually trigger a sync for a Source right now, independent of Edit rights.
Source	Schedule	Set up or modify a Source’s recurring ingestion schedule, independent of Edit rights.
Source	Approve	Approve a newly connected or modified Source before it starts syncing.
Steward	View	See Steward assignments and activity.
Steward	Create / Edit / Delete	Manage Steward assignments.
Steward	Approve	Approve a Steward action or recommendation.
Tag	View	See Tags.
Tag	Create	Create a new Tag.
Tag	Edit	Modify a Tag’s definition.
Tag	Delete	Remove a Tag.
Tag	Approve	Approve a new or AI-suggested Tag before it’s published to the tag library.
Term	View	See glossary Terms.
Term	Create	Create a new Term.
Term	Edit	Modify a Term’s definition.
Term	Delete	Remove a Term.
Term	Approve	Approve a new or AI-suggested Term before it’s published to the glossary — the same Pending → Ready for Review → Approved flow used for assets.

The rows above marked with a resource-specific description (Asset, Metric and Queries, Source, Command Center – Schedule, and Analytics) are confirmed against the product’s live Permission Set matrix and behavior. Rows without a directly observed UI touchpoint (for example Application, Domain, Product, Setting, Steward, Tag, Term, and the Organization types) describe Prizm’s documented Pending → Approved governance pattern applied consistently across resource types; if your workflow needs the exact approval touchpoint for one of these, confirm it against that resource’s own detail page or with your Prizm admin.

Analytics → Approve, explained

What it is: The Analytics resource type covers everything under the Analytics section of Prizm — the built-in Catalog, Observability (Data), Quality, and Exception dashboards, plus any custom dashboard or saved view a user builds there (via Save as view) and shares with others. What Approve does: It gates publishing/sharing a saved Analytics dashboard or view. Create/Edit/Delete let a user build and maintain their own dashboards; Approve is the sign-off needed before a saved dashboard or view is shared more broadly (e.g., shared with a team rather than kept private) — mirroring the same Pending → Approved governance pattern Prizm uses for Metrics (a metric stays Inactive until approved) and Assets (AI recommendations stay pending until someone with Approve accepts them). Where it applies: More → Analytics, on any of the dashboard tabs (Catalog / Observability / Quality / Exception) or a custom saved view reached from the More dropdown next to them. A role without Analytics → Approve can still view dashboards and build/save their own private views, but cannot sign off a dashboard/view for wider sharing.

This module doesn’t expose a distinct “pending dashboard” queue the way Assets or Metrics do — Approve is scoped to the sharing/publishing step for saved views. If your organization needs a more granular breakdown, flag it with your Prizm account team so the product docs can be updated with the exact in-app label.

Access Evaluation Logic

When a request arrives, Prizm evaluates permissions in this order:

Identify the user

Look up the authenticated user and resolve all group memberships.

Collect role assignments

Gather every role assignment — direct (Member tab) and via groups (Group tab) — at the Application level.

Resolve the highest role

Apply the highest-priority role when a user has multiple assignments. Owner (3) beats Steward (2) beats User (1); custom roles at 5+ always take precedence.

Load the Permission Set

Fetch the Permission Set associated with the winning role and read the enabled toggles.

Apply tag constraints

If the assignment includes allow or deny tag constraints (ABAC), filter the resource list accordingly.

Enforce

Return the final access decision. Deny constraints always override allow, even when only a single resource carries a deny tag.

Role Consolidation: All applicable roles are collected from user and group assignments. The highest-priority role’s permissions take precedence. Tag-based filters then further refine which resources are accessible.

Assignment Structure

Access assignments follow a consistent JSON format that maps users or groups to roles on specific resources:

{
  "assignee_type": "user | group",
  "assignee_id": "<user_id or group_id>",
  "resources": [
    {
      "resource_type": "domain | product | app | connection",
      "resource": "<resource_id>",
      "resource_role": "owner | steward | user | <custom_role>",
      "role_priority": 3,
      "assigned_by": "<user_id>",
      "assigned_date": "2025-06-24T00:00:00Z",
      "resource_constraints": {
        "allow": ["tag1", "tag2"],
        "deny": ["PII"]
      }
    }
  ]
}

Key Rules

allow: ["*"] — grants access to all tag variants of the resource
deny: ["PII"] — blocks access to PII-tagged rows/columns even if other constraints allow
A deny on any one resource is honoured even when all other resources in the assignment use allow: ["*"]
Assignments have an optional expiry_date field for time-limited access grants

Assignment Examples

Owner of two domains (no tag restrictions) E.g., Bob is an Owner of Domain Customer360 and Domain Marketing

{
  "resources": [
    {
      "resource_type": "domain",
      "resource_role": "owner",
      "role_priority": 3,
      "resource": "Customer360",
      "assigned_by": "bob",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "allow": ["*"] }
    },
    {
      "resource_type": "domain",
      "resource_role": "owner",
      "role_priority": 3,
      "resource": "Marketing",
      "assigned_by": "bob",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "allow": ["*"] }
    }
  ]
}

Steward scoped to Internal-tagged resources only E.g., Sarah is a Steward of Product MarketingData but only for Internal-tagged resources

{
  "resources": [
    {
      "resource_type": "product",
      "resource_role": "steward",
      "role_priority": 2,
      "resource": "MarketingData",
      "assigned_by": "sarah",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "allow": ["Internal"] }
    }
  ]
}

Group with PII denied across two resources E.g., Group Marketing has Member access but cannot see PII-tagged data

{
  "resources": [
    {
      "resource_type": "application",
      "resource_role": "member",
      "role_priority": 1,
      "resource": "ETL-Pipeline",
      "assigned_by": "priyam",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "deny": ["PII"] }
    },
    {
      "resource_type": "product",
      "resource_role": "member",
      "role_priority": 1,
      "resource": "MarketingData",
      "assigned_by": "priyam",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "deny": ["PII"] }
    }
  ]
}

Global Admin (full access, all resources) E.g., Peter is a global Admin

{
  "resources": [
    {
      "resource_type": "*",
      "resource_role": "admin",
      "role_priority": 5,
      "resource": "*",
      "assigned_by": "peter",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "allow": ["*"] }
    }
  ]
}

User denied for PII Data across all resources E.g.., Ashok is a global Steward but cannot see PII data

{
  "resources": [
    {
      "resource_type": "*",
      "resource_role": "steward",
      "role_priority": 2,
      "resource": "*",
      "assigned_by": "ashok",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "deny": ["PII"] }
    }
  ]
}

Even if only one resource carries a deny constraint while others are tagged as allow, the deny takes precedence for that resource. Deny constraints are always enforced.

Database Schema Reference

Schema Components

Table	Purpose
`users`, `groups`, `user_groups`	Identity model for user and group management
`roles`, `permissions`, `role_permissions`	Role definitions with associated permission sets
`assignments`	Grants roles to users or groups scoped to specific resources
`resources`	Flattened table of all resource types (domain, app, tag, etc.)
`role_precedence`	Priority ranking for conflict resolution
`resource_tags`, `app_domains`	Optional mappings between loosely coupled assets

Assumptions

Assignments exist at either User or Group level, identified by the assignee_type value ("user" or "group").
User-level assignments are implemented in application code by referencing the user_groups table, which stores user-group mapping information.
Access constraints are applied at the resource level (e.g., Domain: "Marketing", Product: "SAP_Prod").
The Assignments table contains only one record per user. The assignee_id field serves as a Unique Index or Business Key.
When no access constraints are defined for a resource, users/groups receive default "allow": ["*"] access.

Access Evaluation Process

The system determines effective permissions through a multi-step evaluation process at runtime:

Identify the user

Identify the user and their group memberships.

Resolve role assignments

Resolve all relevant role assignments — both group-level and user-level — at the Application Level.

Collect permissions

Determine all permissions from the assigned roles.

Apply highest scope

Apply the highest permission scope when conflicts exist between roles.

Apply constraints

Optionally filter results by tag, sensitivity, or ownership constraints.

​Overview

​Core Principles

​Key Entities

​Access

​Members

​Member Fields

​Adding a Member

​Groups

​Group Fields

​Group vs. Direct Assignment

​Roles

​Standard Roles

​Role Definitions

​Custom Roles

​Permission Sets

​Reading the Matrix

​Default Permission Set Coverage

​Permission Set Matrix

​Permission Type Reference

​What Each Action Means

​Permission Actions by Resource Type

​Analytics → Approve, explained

​Access Evaluation Logic

​Assignment Structure

​Key Rules

​Assignment Examples

​Database Schema Reference

​Schema Components

​Assumptions

​Access Evaluation Process

Overview

Core Principles

Key Entities

Access

Members

Member Fields

Adding a Member

Groups

Group Fields

Group vs. Direct Assignment

Roles

Standard Roles

Role Definitions

Custom Roles

Permission Sets

Reading the Matrix

Default Permission Set Coverage

Permission Set Matrix

Permission Type Reference

What Each Action Means

Permission Actions by Resource Type

Analytics → Approve, explained

Access Evaluation Logic

Assignment Structure

Key Rules

Assignment Examples

Database Schema Reference

Schema Components

Assumptions

Access Evaluation Process