--- title: "How to Configure Roles and Permissions" description: "Define roles and permissions that control what users can see and do on the platform." ---
TL;DR
In Settings → Roles, a role controls two things: which parts of the navigation a user can open (page access, set per module and per page inside it), and which actions they can take on each object type (object authority: Read, Write, Approve). You can optionally limit an action to just the objects labelled with certain Groups, Keywords, or Permissible Purposes.
:::note[Admin guide] This page is for administrators with write access to Roles. Roles are assigned to users on the [Users](/user-guide/admin-guide/manage-users/) page. ::: ## What is it? A **role** is a named bundle of permissions. Every user has one or more roles, and their access is the combination of what those roles grant, so if any role enables a page or grants an action, the user has it. A role controls two things: * **Page access** - which parts of the navigation a user can see and open. This mirrors the left sidebar you see in the platform: a **module** is one of the top-level sections listed there (Data Vault, Feature Engineering, Model Studio, Resources, Settings), and a **page** is a single screen nested under it. Data Vault contains Data Table, Data Element, and Quality Profile; Model Studio contains Model; Resources contains Global Functions and Reports. You set access on the module, then fine-tune the individual pages under it. * **Object authority** - which actions a user can take (Read, Write, Approve) on each object type, such as Data Elements, Features, Models, and Policies. The two work together: page access decides whether a user can reach a screen at all, and object authority decides what they can do with the objects on it. A user needs both. Optionally, you can narrow object authority so a role only applies to a subset of objects (for example, only Models in the `Auto Lending` group). ## Before you start * You need write access to Roles in Settings. * If you plan to limit a role to certain objects, the [Groups, Keywords, and Permissible Purposes](/user-guide/admin-guide/organize-objects/) you want to filter by should already exist. ## Configure a role
#### Open the Create Form Go to **Settings → Roles**. The page shows all existing roles with who created and last modified them, and when. Click **+ New Role** and enter a **Name** * (for example, `Model Developer` or `Read-Only Auditor`).
#### Set Module Access and Page Access The form lists every module with its pages nested underneath, in the same structure as the platform's left sidebar. Data Vault holds Data Table, Data Element, and Quality Profile; Feature Engineering holds Feature; Model Studio holds Model; Resources holds Global Functions and Reports; and Settings holds the admin pages such as Roles, Users, and Groups. Set the **Module Access** level for a module and it applies to every page inside it, then adjust individual pages where you want something different. Modules and pages both offer the same three levels: * **Enable** - the module or page is visible and usable. * **Disable** - it's visible but greyed out and not usable. * **Hidden** - it doesn't appear in the navigation at all. A role for a feature developer might Enable Feature Engineering and Data Vault, leave Model Studio on Disable so the user can see models exist without working on them, and set Settings to Hidden so the admin pages never appear. Within a module you can go finer: Enable Data Vault but set Quality Profile to Hidden, and the role gets Data Table and Data Element without ever seeing Quality Profile in the sidebar.
#### Set Object Authority Under **Object Level Authority**, grant the actions this role may perform on each object type: * **Read** - view the object. * **Write** - create and edit the object. * **Approve** - act as a reviewer on approval requests. Available only on approvable objects (Data Element, Dataset, Feature, Framework, Global Function, Model, Policy, Report, Reason Code). In the simple view, each action is a checkbox that grants it across every object of that type. :::note[Retire is granted separately] **Retire** (taking an approved, active, or shadow object out of service) is a distinct permission that is *not* set on this form. A Platform Admin grants it by adding a role to **Roles with Retire Permission** under [Settings → Platform Settings → Governance](/user-guide/admin-guide/configure-platform-settings/#governance). :::
#### Limit the Role to Certain Objects (optional) By default, an action you grant applies to every object of that type. A **Collection** narrows it to only the objects that carry a label you choose, so the role works on part of the registry instead of all of it. Think of it as answering "which ones?" Granting Write on Models says the role can edit models. Adding a Collection of `Groups in Auto Lending` says the role can edit only the auto lending models, and other models stay read-only to it. The labels you filter by are the [Groups, Keywords, and Permissible Purposes](/user-guide/admin-guide/organize-objects/) that people attach to objects when they register them. To set one up: 1. Turn on the toggle next to the object type (its **Additional Specifications** toggle). The row expands to show each action with its own **Collection** toggle. 2. Turn on **Collection** for the action you want to limit. A condition row appears, which you read left to right as a sentence: * **LHS** - the label to match on: **Groups**, **Keywords**, or **Permissible Purpose**. * **Operator** - `in` to include only the values you list, or `not in` to include everything except them. * **RHS** - the values themselves. Pick as many as you want. 3. Click **Add** to add another condition when you need to combine filters. Each action is limited separately, which is what makes a mixed role possible: Read with no Collection plus Write limited to `Groups in Auto Lending` gives a role that can see every model but only edit the auto lending ones. Which labels you can choose from depends on the object type. A Data Table can be limited by **Groups** only, while a Model can be limited by **Groups**, **Keywords**, and **Permissible Purpose**.
#### Grant Superuser Access (optional) On object types that need approval, granting **Write** doesn't let a user edit every draft. It lets them edit only the drafts they registered themselves, not ones someone else started. Read is less restrictive: it also covers objects once they're approved, and any object the user has been assigned to review. Turn on **Superuser** (in the same expanded row as **Collection**) to remove that restriction, so the role can read and write every object of that type regardless of who registered it. * Superuser appears only for the **Read** and **Write** actions, and only on the object types that go through an approval workflow: Data Element, Feature, Dataset, Model, Global Function, Policy, Framework, Report, and Reason Code. * It respects any **Collection** filter you set, so superuser access still stays within the groups, keywords, or purposes you limited it to. * It doesn't override the approval lifecycle. An approved object still can't be edited beyond its [fields marked editable after approval](/user-guide/admin-guide/customize-object-forms/). * It doesn't grant approval. Superuser applies to Read and Write only. Approving an object needs the separate **Approve** action, and the user must be a reviewer in that object's approval workflow.
#### Save Click **Create**. The role is saved and can now be assigned to users.
## What's next * Assign the role to people on the [Manage Users](/user-guide/admin-guide/manage-users/) page. * Set the default role for SSO-provisioned users in [Configure Platform Settings](/user-guide/admin-guide/configure-platform-settings/). * Define the [Groups, Keywords, and Permissible Purposes](/user-guide/admin-guide/organize-objects/) that Collection filters reference.