KDQ Workspaces use a role-based access model to control who can view, run, and manage data quality checks. Configuring the right access ensures that the teams responsible for each domain can operate their Workspaces independently, while protecting sensitive check configurations and results from unintended modification.
KDQ Access Roles
There are three access levels within a KDQ Workspace:
|
Role |
Permissions |
|---|---|
|
Viewer |
Can view check definitions, results, and trends. Cannot create, edit, or run checks. |
|
Editor |
Can create and edit checks, run checks manually, and review results. Cannot manage Workspace settings or members. |
|
Admin |
Full access — can manage Workspace settings, members, connections, schedules, and the K sync configuration. |
In addition to Workspace-level roles, there is a platform-wide KDQ Platform Admin role:
|
Role |
Permissions |
|---|---|
|
KDQ Platform Admin |
Can create and delete Workspaces, manage platform-level connections, and assign Workspace Admin roles. Typically reserved for your KADA system administrator. |
Adding Members to a Workspace
🔒 Only Workspace Admins and KDQ Platform Admins can manage Workspace membership.
Step 1 — Open the relevant KDQ Workspace and navigate to Settings → Members.
Step 2 — Click + Add Member.
Step 3 — Search for the user by name or email address. Users must already have a K platform account — if a user doesn't appear, they may need to be added to K first (see Configuring Users in K).
Step 4 — Select the appropriate role (Viewer, Editor, or Admin).
Step 5 — Click Add. The user will receive a notification that they have been granted access.
Changing a Member's Role
-
Navigate to Settings → Members in the Workspace
-
Find the user in the members list
-
Click the role dropdown next to their name and select the new role
-
The change takes effect immediately
Removing a Member
-
Navigate to Settings → Members
-
Click the … menu next to the user's name
-
Select Remove from Workspace
-
Confirm the removal
⚠️ Removing a member does not delete any checks or results they created. Their contributions remain in the Workspace.
Recommended Access Patterns
|
Scenario |
Recommended setup |
|---|---|
|
Domain teams running their own DQ checks |
Each domain team has at least one Admin and several Editors in their Workspace |
|
Governance team needs read-only visibility across all Workspaces |
Add governance users as Viewers across relevant Workspaces |
|
Centralised DQ team managing all checks |
Single Workspace with the DQ team as Editors/Admins; data owners added as Viewers |
|
Sensitive data domain requiring restricted access |
Create a dedicated Workspace and limit membership to approved team members only |
Workspace Access vs K Platform Access
KDQ Workspace access is separate from K platform roles. A user needs both:
-
A K platform account with an appropriate role (see K User Roles) to view DQ results on Data Profile Pages in K
-
KDQ Workspace membership to access, manage, or run checks directly within the KDQ tool
Data consumers who only need to see DQ results in K (on the Data Profile Page) do not need KDQ Workspace access — they only need a standard K platform account.
Configuring Access via Azure AD / Entra ID
For organisations using SSO with Azure Active Directory (Entra ID), Workspace access can be configured via Entra Groups mapped to KDQ roles. This process involves:
-
Creating a KDQ workspace role in KDQ
-
Configuring a Client Scope and Role in the K User Administration portal (Keycloak)
-
Creating an Entra Group with the appropriate App role value
-
Adding role mappers in the K platform's Identity Provider settings
Contact your KADA administrator for the detailed steps to configure SSO-based workspace access for your environment.
💡 Tip: If your organisation uses teams in K, consider aligning KDQ Workspace membership to the same team structure. This makes it easier to manage access as your organisation grows and teams change.