Roles mapping groups

Map external groups to platform audiences and roles.

Roles Mapping — Groups

The Groups screen is where IT administrators maintain the library of external identity groups that DPMS can use when assigning platform roles to federated users. When your company connects an identity provider — such as Microsoft Entra ID, Google Workspace, or any SCIM-compatible directory — users log in automatically, but DPMS needs to know which permissions to give them. That decision is driven by role mappings, and role mappings can only reference groups that exist in this catalogue. Think of the Groups screen as the authoritative address book: you build it here, and the role-assignment form on the General tab draws from it.

Compliance officers and auditors will often visit the read-only Roles Mapping index to review the current state. IT administrators come here specifically to add new groups, correct existing ones, or remove entries that are no longer valid.

How to open it

You need the IAM read permission to see the Identity & Access Management menu at all. To create, edit, or delete groups you also need the IAM edit permission. If you only have read access, the edit button on the Roles Mapping index will be hidden or will show a tooltip explaining the missing permission.

To reach the Groups screen:

In the left-hand sidebar, click IT Settings.
Under IT Settings, open Identity & Access Management (IAM).
Click Roles Mapping.
On the Roles Mapping index that loads, click the Edit button (pencil icon).
In the edit view that opens, click the Groups tab in the two-tab strip near the top.

What you see

The edit view has a two-tab navigation strip running just below the page title. The left tab is labelled General — that is where you assign groups to platform roles. The right tab, Groups, is where you are now.

Below the tab strip, the main content area shows a table of external groups. The table title Groups appears in bold above the rows. Each row represents one group that DPMS knows about. In the top-right corner of the table area, there is a Create action button — the primary way to add a new group. At the far right of each row, a trailing-action control (three-dot menu) gives you a Delete option for that specific group. At the top of the table, a single filter tab labelled All is active — there are no additional filtered views on this screen, so all groups are always visible at once.

One important detail about the page header: on the Groups tab, the top-level Save button that appears on the General tab is deliberately hidden. Group operations each save themselves individually, so there is no top-level form to submit here. If you switch back to the General tab, the Save button reappears.

Working with this screen

Adding a new external group before a SCIM sync

The most common reason to add a group manually is timing: a new department group has just been created in your identity provider, but the next SCIM synchronisation hasn't run yet, and you need to map it to a platform role right now.

On the Groups tab, click the Create button in the top-right corner of the table. A small dropdown appears with the option Create Group — click it.
A creation form opens. Type the group's display name in the Name field — for example, Legal Operations. This is what users will see in the role-assignment dropdowns.
In the External Identifier field, enter the exact identifier that your identity provider uses for this group. For Entra ID, that is typically the group's object GUID. For SCIM providers, it is the externalId value. The identifier must match the provider precisely; if it doesn't, DPMS will not be able to reconcile this entry with future SCIM-provisioned data and you may end up with duplicate records.
Click Save on the creation form. DPMS saves the group and returns you to the Groups tab, where the new entry now appears in the table.
Switch to the General tab. The group you just created will now appear in the async multi-select dropdowns, ready to be assigned to a platform role.

Correcting a group's name or identifier

After a company rebranding or an internal restructure, group names in your identity provider may change. If DPMS still shows the old name, users won't recognise the group in the role-mapping dropdowns. Here's how to update it:

Locate the group in the table. If your list is long, scroll down — the table loads more entries automatically as you reach the bottom.
Click anywhere on the group's row. The group edit form opens, pre-filled with the current Name and External Identifier.
Update the Name field to the new display name. Leave the External Identifier unchanged unless the identifier itself has changed in the identity provider — changing an identifier that is still in use will break the reconciliation between DPMS and your directory.
Click Save on the edit form. DPMS updates the record and returns you to the Groups tab. The new name will immediately appear in the table and, going forward, in the role-assignment dropdowns on the General tab.

Removing an obsolete group

When a department group is retired in your identity provider, you should remove it from DPMS to keep the catalogue clean and avoid confusion in the role-mapping dropdowns.

Find the group in the table.
Click the trailing-action menu (the three-dot icon) at the end of that row.
Select Delete. A confirmation prompt appears — this is standard across all DPMS list screens. Confirm the deletion.
The group is removed from the catalogue and the row disappears from the table.
Important: Before or after deleting, switch to the General tab and check whether this group was assigned to any platform roles. If it was, that mapping will become a dangling reference — it won't automatically be removed. Open any affected role assignments, remove the deleted group from the selection, and click Save on the General tab. See Tips & common pitfalls for more detail.

Auditing the group catalogue before making changes

If you are new to the organisation, or if you want to understand the current state before modifying anything, the Groups tab works equally well as a read-only audit view.

Navigate to the Groups tab (see How to open it).
Scroll through the table. Each row shows the group Name and its Creation Date. The creation date tells you when the record was added to DPMS — either manually or via a SCIM sync.
When you're done reviewing, click the back arrow in the top-left of the page to return to the read-only Roles Mapping index. Nothing will be saved.

Field reference

The following fields appear on the group creation and edit form, which opens when you click Create Group or click a row in the table.

Name — The display name for the group as it will appear throughout DPMS, including in the role-assignment dropdowns on the General tab. Required. If your DPMS instance supports multiple languages, you may see this field support localised values; the English value is the primary display label.
External Identifier — The unique identifier that your identity provider uses for this group. For Microsoft Entra ID this is typically a GUID (for example, a1b2c3d4-e5f6-7890-abcd-ef1234567890). For generic SCIM providers it is the externalId field value. This field is required and must match the identity provider exactly. DPMS uses it to reconcile manually created records with groups pushed by SCIM provisioning. If you leave this different from the real identifier, you may end up with duplicate group entries after the next SCIM sync runs.

How this connects to the rest of DPMS

The Groups catalogue exists to support one downstream purpose: populating the role-assignment dropdowns on the General tab of the same Roles Mapping edit screen. Every time an administrator opens the General tab and selects which groups should receive a particular platform role, the options in those dropdowns come from the Groups catalogue you manage here.

When a federated user logs in through your identity provider, DPMS checks their group memberships against the role mappings configured on the General tab. The result of that check determines which platform role — and therefore which permissions — the user receives across every module in DPMS. That means what you configure here has a direct downstream effect on who can view risk assessments, edit ROPA records, manage vendor agreements, and access every other part of the system.

There is also an alternative group-creation path worth knowing about: on the General tab, an administrator can type a new group name directly into the async multi-select dropdown and press Enter to create a group on the fly. That creates a group in the same catalogue, but the external identifier will be set to the typed text, which may not match the real identifier in your identity provider. If you use that shortcut, come back to the Groups tab afterwards and edit the external identifier to the correct value.

If your organisation has SCIM provisioning enabled (configured elsewhere in IAM settings), your identity provider will also push groups into this same catalogue automatically. Manually created groups and SCIM-provisioned groups coexist in the same table.

After completing your group catalogue, the logical next step is to switch to the General tab and assign groups to platform roles, then confirm the mappings by reviewing the read-only Roles Mapping index.

Tips & common pitfalls

Heads up: Deleting a group does not clean up role mappings. If a group is already assigned to one or more platform roles on the General tab, deleting it from the Groups catalogue will leave a dangling reference in that configuration. The role mapping won't automatically disappear. Always check the General tab after deleting a group and re-save any affected role assignments to remove the orphaned entry.

The Save button is missing on the Groups tab — that's intentional. Each group operation (create, edit, delete) saves immediately when you complete the individual form or confirm the deletion. There is no top-level form to submit. The Save button only appears on the General tab.

Tip: The External Identifier must match your identity provider exactly. When creating a group manually, copy the identifier from your directory rather than typing it from memory. Even a single character difference will prevent DPMS from matching the entry to SCIM-provisioned data, which can lead to duplicate records.

Manually created groups and SCIM-provisioned groups share the same table. Both types appear together in the catalogue and in the role-assignment dropdowns. If you create a group manually before SCIM runs, you may see a duplicate entry appear after the sync. Compare external identifiers carefully if you suspect duplicates.
Using the inline creation shortcut on the General tab sets the external identifier to whatever you typed. If you type a display name and press Enter in the role-assignment dropdown, DPMS creates a group with that text as both the name and the external identifier. Unless that text happens to be the real identifier in your directory, you'll need to come back to the Groups tab and fix the external identifier.
There is no archive or deactivate option. Unlike the Tokens screen, which has Active and Expired tabs, the Groups table shows everything under a single All tab. A group is either present in the catalogue or deleted. If you need to retain a group record for audit purposes but no longer want it to appear in role-assignment dropdowns, your only options are to leave it as-is or delete it. Plan your catalogue accordingly.
Member counts shown in role-assignment dropdowns reflect the last sync, not live data. The number of members displayed alongside group names in the General tab's dropdowns is updated during SCIM or Active Directory syncs, not in real time. If accuracy is critical, trigger a manual sync from the Active Directory screen before reviewing these counts.

Roles mapping groups