Browse roles

List all built-in and custom roles available on the platform.

Browse Roles

The Roles screen is the central place in DPMS where you decide what every category of user is allowed to see and do. Whether you need a read-only auditor who can look but never touch, a compliance coordinator who can export records but not delete them, or a full data protection manager with access to everything, those boundaries are drawn here. IT administrators and Data Protection Officers come back to this screen whenever the organisation grows, a new compliance programme starts, or an audit requires tightening access — because every permission in the platform ultimately traces back to a role configured on this screen.

How to open it

Navigate to IT Settings in the left-hand sidebar (the cog icon section), then click Roles. The sidebar highlights Roles as the active item while you are here.

You need the IT Settings – Roles (Read) permission to view the list. To create a new role you also need the IT Settings – Roles (Create) permission; to edit an existing custom role you need the IT Settings – Roles (Edit) permission. If your account does not have read access, DPMS will show a "Forbidden" error page instead of the list.

What you see

The content area shows a short title for the Roles module followed immediately by the roles table — no tab strip, just a flat list of every role in your system. In the top-right corner sits a Create button (an animated icon) that opens a small dropdown with a single option, Create Role.

Each row in the table represents one role. Rows for system roles (the built-in roles that ship with DPMS) display a small circular Priverion logo badge next to the role name, which is an instant visual cue that those roles cannot be changed. Rows for custom roles — the ones your organisation has created — show a trash icon on the far right and are fully editable. There is one special row: the built-in Employee role contains an extra toggle switch in its row that controls whether employees automatically inherit permissions on linked sub-records. All other rows leave that column empty.

When your organisation has many custom roles, the table loads more rows automatically as you scroll toward the bottom, so you never need to click through pages.

Working with this screen

Setting up a new custom role from scratch

When none of your existing roles fits a new team member or business function, click Create in the top-right corner and select Create Role from the dropdown. This takes you to the role creation form.

At the top of the form, type a clear and descriptive name in the Role name field — for example "Read-only Auditor" or "Compliance Coordinator". The name field is required; DPMS will not let you save without one.

Below the name sits the Permissions Assignment panel. This is where all the access control decisions happen. It shows one collapsible accordion row per DPMS module — covering everything from ROPA and TOMs to Vendors, Assets, Incidents, Assessments, Workflow, and IT Settings itself. Each row starts collapsed, showing only the module name, a coloured badge counting how many permissions are currently enabled (blue if any are on, red if none), and two quick links: Select all and Deselect all.

To grant a permission, click on the row for the module you want — say, "ROPA" — to expand it. The expanded panel shows four columns of checkboxes:

  • Main Actions (Create, Read, Edit, Read Only to Assigned, Edit Only to Assigned, Delete, Duplicate)
  • Sharing (Publish, Push Changes, Load from Organisations, Pull Changes, Unlink, Change Request)
  • Import/Export and Element Settings (Import, Export, Assign Workflow, AI Functionality)
  • Automations and Risk Management (Reassign in Step, Risk Edit Deadline)

Not every checkbox appears for every module — only the permissions that make sense for that entity are shown. Click the checkboxes that match what this role should be able to do. Each ticked checkbox turns blue to confirm it is active.

Once you are satisfied with the permission configuration across all modules, click Save in the form header. DPMS validates that at least one permission checkbox is ticked somewhere in the form. If you accidentally click Save with nothing selected, a notification message appears at the top of the screen — nothing is lost, and you can simply tick the appropriate checkboxes and try again. On a successful save, the new role appears in the roles list immediately.

After creating the role, your next step is to go to User Management (also under IT Settings) to assign this role to the relevant users.

Editing an existing custom role

When a DPO or compliance officer needs a change — for example, adding export permissions ahead of an annual audit — find the role in the table and click anywhere on its row. DPMS navigates you to the edit form for that role, pre-populated with all the permissions currently configured.

If you know which module you need to change, use the Search bar in the top-right of the Permissions Assignment panel. Typing "ropa" collapses every accordion panel except the ROPA row, making it easy to find the right checkboxes without scrolling through 50+ modules. Clearing the search bar brings all panels back.

Inside the expanded accordion, tick or untick the checkboxes that need to change. Be aware of two automatic behaviours DPMS enforces:

  • Enabling a higher-level permission automatically enables its prerequisites. If you tick Export, DPMS also ticks Read for you — because exporting something you cannot read would not make sense. If you tick Push Changes, both Read and Edit are enabled automatically.
  • Disabling Read can cascade widely. If you untick Read for a module (and Read Only to Assigned is also off), DPMS automatically unticks Create, Edit, Export, Import, AI Functionality, Publish, and several other permissions for that same module all at once. This is by design — all those actions depend on being able to read the records first.

Click Save when done. The change takes effect immediately for every user currently holding that role across the whole platform.

Reviewing a built-in system role without changing it

Before handing compliance documentation to an external auditor, a DPO might want to confirm exactly what the built-in "Data Protection Manager" role can do. Click the role's row in the table. The edit form opens, but every checkbox is greyed out and non-interactive — system roles are fixed by Priverion and cannot be modified. The Save button is hidden entirely. You can read through each module's permissions freely and use the Search bar to jump to specific modules. When done, click the back arrow to return to the list.

Adjusting the Employee role's sub-element access

One special permission lives directly in the roles list rather than in a separate form. The built-in Employee role has a toggle switch in the table row itself, under the "Access to sub elements" column. When this toggle is on, employees automatically see linked sub-records — for example, the assets linked inside a processing activity — without needing an explicit individual permission grant on each sub-record.

You can flip this toggle directly in the table. The change saves immediately via a background request; there is no separate Save button. If the request succeeds, the toggle stays in its new position. If something goes wrong, it reverts and a brief error message appears. If you accidentally toggle it, simply toggle it back straight away.

Deleting a custom role you no longer need

Custom roles that are no longer in use can be removed by clicking the trash icon on the far right of the role's row. DPMS will ask you to confirm before deleting. Note that this option is available only for custom roles — system roles do not show the trash icon.

Field reference

Role name — A human-readable label for the role. Make it specific enough that an administrator can understand the role's purpose at a glance (for example, "Finance Read-only" rather than "Role 3"). This field supports multiple languages; DPMS can auto-populate other language translations if automatic translation is configured for your account. Required. The form will not save without a value here.

Permissions Assignment search bar — A free-text filter that narrows the accordion list to modules whose name or permission labels match your search term. It is a navigation aid only — it does not restrict which permissions are saved when you click Save. The full permissions map is always saved.

Individual permission checkboxes — Each checkbox controls a single permission type for a single module. Greyed-out checkboxes indicate that a prerequisite permission is not yet enabled (for example, Edit is always greyed out until Read is on for the same module). For system roles, every checkbox is greyed out regardless.

How this connects to the rest of DPMS

Roles sit at the very top of DPMS access control. Before you can assign any user to a meaningful set of permissions, the role defining those permissions must exist here. Once a role is saved, it becomes available for selection in User Management, where it can be assigned to individual user accounts.

Every role you configure here directly affects what users see throughout the platform:

  • The AI helper button on forms across DPMS — for any module where you have not granted the AI Functionality permission — will be greyed out or absent for users holding that role.
  • The Publish button on ROPA records, TOMs, and other publishable items only appears if the Publish permission is enabled for that module in the user's role.
  • Import and Export buttons throughout the application (for example, exporting a ROPA to Excel, importing a vendor list) depend on the Import and Export permissions for the respective module.
  • Workflow controls — assigning or reassigning steps — only appear when the appropriate workflow permissions are granted.
  • The ROC (Record of Compliance) module has a special dependency: its Read permission cannot be enabled at all until Read is active for TOMs, Assets, and Risk Scenarios simultaneously.
  • The sharing infrastructure — Push Changes, Pull Changes, Load from Organisations — across every module is governed entirely by permissions set on this screen.

After finishing your role configuration here, your typical next step is to go to User Management to assign the role to the relevant users.

Tips & common pitfalls

Heads up: If you click Save and nothing seems to happen, check whether at least one permission checkbox is ticked anywhere in the Permissions Assignment panel. DPMS requires at least one permission to be active before it will save the role. The error message appears as a brief notification at the top of the screen, not as an inline field error.
Heads up: Disabling the Read checkbox for a module — when Read Only to Assigned is also off — will simultaneously remove Create, Edit, Export, Import, AI Functionality, Publish, and many other permissions for that module in a single cascade. This is intentional but can look alarming the first time it happens. Review the full checkbox state for the module after making a Read change.
  • Enabling a permission also enables its prerequisites silently. If you tick Export on a module, DPMS will automatically tick Read as well. After enabling any sharing, import/export, or workflow permission, glance at the Main Actions column to confirm the prerequisite state is what you intended.
  • System roles cannot be changed. The Save button is hidden and all checkboxes are greyed out for built-in system roles. If the built-in permissions do not meet your organisation's needs, create a new custom role rather than attempting to modify a system one.
  • The ROC module's Read checkbox may appear permanently disabled. This is expected behaviour if Read is not yet enabled on all three of TOMs, Assets, and Risk Scenarios. Enable Read on those three modules first, then return to the ROC panel.
  • The Employee role's sub-element toggle is the only in-table permission control. It updates live without a confirmation step. All other permission changes require opening the edit form and clicking Save.
  • The Search bar is a navigation aid, not a filter for saving. Making permission changes while a search is active is fine — when you click Save, the entire permissions map is saved, not just what was visible on screen.
  • The back arrow discards unsaved changes. The role creation and edit forms do not auto-save. If you navigate away using the back arrow, any checkbox changes you have made since the last Save will be lost.


Was this article helpful?