Global and Namespace Roles management page

Overview

Validio uses permission-based roles to provide granular control over user access to both global and namespaced resources. This guide discusses how to create and manage Roles in your Workspace. For more information about role based-access controls work, see About Validio RBAC.

Permission Scopes

Permissions are categorized by their reach within the platform. Each role grants a specific combination of READ and WRITE permissions to resources at one of two levels:

Global roles: Governs access to shared resources that exist workspace-wide, such as catalog assets and tags.
Namespace roles: Governs access to resources within specific, isolated namespaces, such as channels and credentials. These permissions can be assigned to individual users or inherited through team membership.

Role Types

Validio offers two types of roles to balance simplicity with flexibility:

Role Type	Decription
System	The standard, predefined roles--Admin, Editor, and Viewer. They provide broad access levels, ranging from full administrative control to read-only access, and cannot be modified.
Custom	User-defined combinations of `READ` and `WRITE` permissions for individual resources, to meet specific, granular security requirements.

Custom roles enable you to follow the Principle of Least Privilege, ensuring users have only the minimum access required for their tasks. For example, while workspace settings typically require a Global Admin (with full write access across the platform), you can now create a "Settings Manager" custom role. This role can be configured with WRITE permissions for Settings while remaining READ-only for all other resources.

Adding a Custom Role

To add a custom Global or Namespace role,

Navigate to Workspace > Roles
For the relevant level (Global or Namespace), click + New role
Name: Enter a unique and descriptive name.
(Optional) Description: Describe the role's capabilities.
Resources Grant READ or WRITE permissions to each resource.
Click Create to save and create the new role.

Custom Role Examples

The following table includes examples of custom roles you can add:

Custom Role	Scope	WRITE Permissions	Description
Settings Manager	Global	Settings	Ability to modify workspace configurations while viewing all other resources.
Incident Manager	Namespace	Incidents	Ability to triage incidents without modifying validators or configuration.
Validator Editor	Namespace	Filters, Segmentations, Validators, Windows	Ability to conigure and manage validators independent from sources.

Resolving Permission Conflicts

Users can have multiple roles: the global role that they are assigned when their account is created, the global role they have via team membership, and their role assignment within a namespace which can be direct or via team membership.

When there are conflicting permissions, the user's final access-level depends on the permission scope and whether the User has a direct role assignment:

Permission Scope	Direct User role exists?	Final role
Global	N/A	Merge all direct user and global team roles, and the highest permission for each resource applies.
Namespace	Yes	Direct user role applies, while the team role is ignored.
Namespace	No	Merge all team roles, and the highest permission for each resource applies.

Global-level Permissions

At the global-level, all roles (direct user assigned roles and global team roles) are considered. The permissions from all resources are merged, and the highest level for each resource applies to the resulting permission. For example:

User direct global role: Editor (users:READ, teams:READ, namespaces:WRITE)
Team A global role: Admin (users:WRITE, teams:WRITE, namespaces:WRITE)
Team B global role: Viewer (users:READ, teams:READ, namespaces:READ)

Resulting permission: Merged (users:WRITE, teams:WRITE, namespaces:WRITE)

User Direct Role Exists

If a user has a direct namespace role assignment, it takes precedence over all team roles in that namespace. Team roles are ignored when a direct user assignment exists. For example:

Namespace: "Production"
User direct role: Viewer (source:READ, incident:READ)
Team A role: Editor (source:WRITE, incident:WRITE)

Resulting permission: Viewer (source:READ, incident:READ)

Multiple Teams with No Direct Role

If a user has no direct role in a namespace but belongs to multiple teams with roles in that namespace, all team permissions are merged and the highest permission for each resource is applied. For example:

Namespace: "Development"
User direct role: None
Team A role: Incident Manager (incident:WRITE, source:READ)
Team B role: Source Manager (source:WRITE, incident:READ)

Resulting permission: Merged (incident:WRITE, source:WRITE)