Skip to content

How to Configure Roles and Permissions

TL;DR
In Settings → Roles, a role controls two things: which modules and pages a user can see (page access), and which actions they can take on each object type (object authority: Read, Write, Approve). Use Collection filters to scope authority to objects with certain Groups, Keywords, Permissible Purposes, or status.

Admin guide

This page is for administrators with write access to Roles. Roles are assigned to users on the Users page.

What is it?

A role is a named bundle of permissions. Every user has one or more roles, and access is the union of what those roles grant. A role defines:

  • Page access: whether each module and its pages are Enabled, Disabled, or Hidden.
  • Object authority: which actions (Read, Write, Approve) the role can perform on each object type.
  • Collection scope (optional): filters that narrow authority to a subset of objects.

Roles are managed in Settings → Roles. There are no built-in Admin or Master roles in the source; every role is defined here.

Before you start

  • You need write access to Roles in Settings.
  • If you plan to use Collection filters, the Groups, Keywords, and Permissible Purposes you want to filter by should already exist.
  • Decide up front whether the role is a broad administrative role or a narrow, scoped one. Scoped roles are built with Collection filters.

How to Configure a Role

Step 1: Open the Roles list

Go to Settings → Roles. The list shows each role's name, who created and last modified it, and when. Click + New Role.

Step 2: Name the role

Enter a Name (required). The name is locked once the role is saved, so pick a clear one (for example, Model Developer, Fair Lending Reviewer, Read-Only Auditor).

Step 3: Set page access per module

For each module (Data Vault, Feature Engineering, Model Studio, Underwriting, Settings, and so on), set the Module Access level. Each page within the module can then be set individually.

Access level What it does
EnableThe module/page is visible and usable.
DisableThe module/page is visible but greyed out / not usable.
HiddenThe module/page does not appear in the navigation at all.

Step 4: Set object authority

For each object type (Data Element, Feature, Model, Policy, Report, and so on), grant the actions this role may perform:

Action What it allows
ReadView the object.
WriteCreate and edit the object.
ApproveAct as a reviewer on approval requests. Available only on approvable object types (Data Element, Dataset, Feature, Framework, Global Function, Model, Policy, Report, Reason Code).

In the simple view, each action is a checkbox per object type. That grants the action across every object of that type.

Step 5: Scope authority with Collections (optional)

Some object types support Collection filtering, which narrows an action to objects matching a set of conditions. Turn on Collection for an action to build conditions of the form Attribute IN / NOT IN values:

Filter attribute Scopes by
GroupsThe object's group (for example, only objects in the Auto Lending group).
KeywordsKeyword tags on the object.
Permissible PurposeThe compliance purpose tagged on the object.
StatusApproval status (Draft, Pending Approval, Approved, and so on). Not available for the Approve action.

Each condition uses the operator IN (matches the listed values) or NOT IN (matches everything except them). Add multiple conditions to combine filters. The available filters depend on the object type (for example, Data Tables filter by Group only, while Models filter by Group, Keyword, Permissible Purpose, and Status).

Tip

Use Superuser on Read or Write (available for workflowable objects) to bypass Collection filters for that action, granting blanket access while keeping filters on the other actions.

Click Save.

How Access Is Resolved

When a user has multiple roles, their effective access is the union of all roles' grants. Page access and object authority stack: if any role enables a page or grants an action, the user has it. Collection filters scope only the role that defines them; an unscoped grant in another role still applies.

What's next