Edit an organizational unit

Edit an Organizational Unit

Organisational units (OUs) are the backbone of your compliance structure in DPMS. Every ROPA entry, DPIA, task, vendor relationship, and risk assessment can be scoped or filtered by OU — so keeping them accurate matters far beyond just a name change. The Edit Organisational Unit screen is where you update an existing unit's identity, position in the reporting hierarchy, responsible contacts, and Active Directory group mappings. Whether you're reflecting a real-world restructuring, correcting a setup mistake, or onboarding a new department head, this is the screen you'll come back to.

How to open it

• In the left sidebar, click General Settings.
• In the sub-menu that opens, scroll to Organizational Units (listed under the Compliance Settings section, between Departments and IGDTA Configuration).
• On the Organizational Units list, click any row to open it — or use the row's action menu and choose Edit.

You need the Compliance Settings read permission for the menu item to appear. Editing requires the corresponding edit permission on Organizational Units. If you navigate to the URL directly without the right permission, DPMS will show a standard access-denied page.

What you see

The screen uses the standard two-column General Settings layout. The left quarter of the screen shows the General Settings navigation menu — a vertical list of all compliance and risk settings areas. The currently active item, Organizational Units, is highlighted. Above the main content area, a breadcrumb bar shows "General Settings › Organizational Units", with small left (‹) and right (›) arrows for jumping to adjacent settings sections (Departments or IGDTA Configuration).

The right portion — the edit form itself — opens with a back arrow and the title Organizational Units at the top, and a Save button in the top-right corner. A thin blue horizontal line separates the heading from the form body below.

The form is divided into clearly labelled sections: General (name, description, responsible persons), Active Directory (AD) Groups, Hierarchy (parent unit), and a read-only view of any sub-units nested beneath this OU. There are no tabs — everything is visible in a single scrollable page, with thin dividing lines between sections. A second Save button and a cancel link appear at the bottom of the form as well.

Working with this screen

Renaming a unit after a reorganisation

This is the most common reason to land here. Perhaps "Finance" has become "Finance & Controlling" after a merger, or "IT Support" has been rebranded as "Digital Workplace Services".

• Open the OU from the Organizational Units list.
• In the Name field at the top of the General section, clear the existing text and type the new name. If your organisation uses multiple languages in DPMS, the field stores a translation per language — editing here updates the name in the currently active interface language. Staff using a different language will continue to see the old translation until it is updated separately.
• If the unit's function has also changed, scroll down to the Description field and update the text to reflect the new scope.
• Click Save. DPMS sends the updated data to the backend, shows a success notification, and the Organizational Units list reflects the new name immediately.

Heads up: The Save button at the top-right and the one at the bottom of the form do exactly the same thing. Use whichever is more convenient for your scroll position.

Assigning or changing the responsible person

When a new department head joins, or when the previous responsible person has left the company, you need to update this field so that the right person receives notifications and appears correctly in audit reports.

• Scroll to the Responsible Person selector in the General section.
• Click the field to open the people-picker dropdown. Start typing the person's name — the list filters as you type.
• Select the correct user. You can assign more than one responsible person if your organisation requires it.
• If the previous person was deactivated in the system, their name may still appear as a greyed-out placeholder. Remove them and select the current contact.
• Click Save. From this point, all compliance reports, task assignments, and notifications scoped to this OU will reference the updated responsible person.

Tip: If you are editing an OU for the first time and no responsible person was previously set, the field may default to your own name. Check this before saving to ensure the correct person is recorded.

Mapping an Active Directory group to an OU

If your organisation uses Microsoft Azure AD or a similar directory, linking an AD group to an OU automates membership management. Users who join the AD group automatically gain the corresponding OU association in DPMS — no manual updates required.

• Scroll to the AD Groups section.
• Click the AD Groups dropdown. The list shows all AD groups that have been pulled in from the last successful Active Directory sync in IT Settings.
• Select the relevant group or groups. If the group you need is not listed, the most likely cause is that the AD sync has not yet run since the group was created. Go to IT Settings › Active Directory, trigger a manual sync, then return to this screen.
• Click Save. From the next login or session refresh, users who are members of that AD group will be recognised as belonging to this OU for access-scoping and filtering throughout DPMS.

Heads up: The AD Groups field is entirely optional. OUs without an AD group mapping work normally — users can still be assigned to the OU through other mechanisms such as the Responsible Person field or audience settings. The AD mapping simply automates membership.

Moving a unit to a different position in the hierarchy

During a reorganisation, a team may shift from one division to another — for example, "Customer Support" moves from a top-level position into the "Operations" division.

• Scroll to the Hierarchy section.
• Click the parent selector. A dropdown or tree view shows the full list of existing OUs, including deeply nested ones. For large organisations, scroll carefully.
• Select the new parent unit. The backend will prevent you from selecting the OU being edited as its own parent (which would create a circular structure).
• Before saving, scroll down to the Organizational Units section at the bottom of the form. This shows any sub-units currently nested beneath the OU you are editing. Changing the parent will move the entire subtree — every child OU relocates along with the parent. Review these carefully to understand the full scope of the change.
• Click Save. All ROPA records, tasks, and reports that were scoped to the relocated unit will now reflect the updated hierarchy position.

Heads up: Moving a parent OU affects all child units at once. If you have three sub-teams nested under a division and you move the division, all three sub-teams move with it. This is intentional but can affect access scoping and report filtering across DPMS — review the downstream modules after a hierarchy change.

Reviewing an OU before a major change (read-only review)

Sometimes you want to understand what is attached to a unit before you restructure or delete it. The edit screen is a good place to do this inspection, even if you end up saving nothing.

• Open the OU's edit screen.
• Check the Responsible Person field to see who is currently accountable.
• Check the AD Groups field for any directory group mappings that will need to be cleaned up.
• Scroll to the bottom and review the Organizational Units sub-units section. If child OUs are still listed here, they will need to be reassigned or removed before this unit can safely be dissolved.
• Click the back arrow or the Cancel link at the bottom of the form. No changes are saved, and you return to the Organizational Units list.

Field reference

• Name — The display name of the organisational unit, shown everywhere the OU is referenced in DPMS (ROPA, tasks, reports, dropdowns). Accepts free text. Stored per language when multilingual names are in use. Required — leaving this blank will trigger a validation error on save.
• Description — An optional longer text explaining the unit's purpose or scope. Shown in detail views and some reports. No length restriction, but concise descriptions are easier to maintain. Optional.
• Responsible Person — One or more users formally accountable for this OU. These users appear in compliance reports and audit exports, and receive notifications related to the OU. Selected from the platform's full user directory. If you leave this unchanged and no previous value exists, the form may default to the currently logged-in user — verify before saving.
• AD Groups — One or more Active Directory or Azure AD groups linked to this OU. Users who belong to these groups are automatically associated with the OU for access-scoping purposes. Populated from the last successful AD sync. Optional.
• Hierarchy (Parent Unit) — The parent OU under which this unit sits in the reporting tree. Selecting a parent places this OU as a child in the hierarchy. Leave blank to make this OU a root-level unit. Cannot be set to the OU itself (circular reference prevention). Changing the parent moves all child OUs too.
• Organizational Units (sub-units) — A read-only display of child OUs currently nested beneath this unit. Not directly editable here — sub-units are created and managed from the index page. Use this section to assess the impact of hierarchy or naming changes.

How this connects to the rest of DPMS

Organisational units are a foundational reference object. Changes you make here ripple across every module that uses the OU as a scoping or filtering dimension:

• ROPA, DPIAs, Tasks, Assets, Vendors, TOMs, Incidents, Assessments, Projects, Meetings & Activities — all of these modules have fields that reference OUs. An incorrectly named or misplaced OU will show incorrect data in every one of them.
• Audience access scoping — Audiences can be restricted to specific OUs. If an OU is renamed, removed, or restructured, double-check that your audience configurations still scope access correctly.
• Compliance dashboards and reports — Risk reports and compliance dashboards allow filtering by OU. An incomplete or incorrectly structured OU tree means incomplete report coverage.
• Active Directory sync — The AD groups you link here feed the automatic user-to-OU assignment feature. Without correct mappings, users joining a new AD group won't automatically pick up the OU association.

After editing an OU, consider reviewing any ROPA records, tasks, or audience definitions that reference the unit to confirm they still reflect your intended structure. If you renamed a unit or moved it in the hierarchy, the change is immediate across all linked records — there is no separate publish or approve step.

You can navigate directly to the Departments settings page (the previous section) or the IGDTA Configuration page (the next section) using the ‹ and › chevron arrows in the breadcrumb bar at the top. Note that navigating away via these chevrons without clicking Save first will silently discard any unsaved changes.

Tips & common pitfalls

Tip: Always click Save before using the breadcrumb navigation arrows. The chevrons (‹ and ›) navigate immediately — they do not ask you to confirm unsaved changes, and any edits you've made will be lost.

Heads up: If Save fails with a conflict warning even though you were the only editor, it is likely that a background process (such as an AD sync that updated OU membership records) saved to the same record while you had the form open. Simply reload the edit form and try again — your intended changes do not need to be re-entered from scratch.

• AD Groups dropdown is empty, but Active Directory is connected. The list is populated from the last successful sync. If new groups were created in Azure AD after the last sync, they won't appear yet. Go to IT Settings › Active Directory, trigger a manual sync, and then return to this screen to find the new groups.
• Moving a parent unit affects the entire subtree. If the OU you are editing has child OUs, changing its parent will relocate all of them simultaneously. Scroll to the sub-units section before saving a hierarchy change to see exactly what will be moved.
• The Name field is language-specific. DPMS stores OU names as multilingual values. Editing the name in the English interface only updates the English version. If your organisation uses other languages (German, French, etc.), the translated names are not updated automatically and will need to be reviewed separately.
• Navigating away without saving discards all changes silently. Neither the back arrow at the top, the Cancel link at the bottom, nor the breadcrumb chevrons show a "you have unsaved changes" confirmation dialog. Click Save first.
• Check the Responsible Person field before saving a new record. If no responsible person was previously assigned, the field may default to your own account. Make sure the correct person is selected before saving, to ensure accurate accountability records.