---
title: "How to Configure Policy Acknowledgement Roles and Permissions"
description: "Assign role groups in Policy Admin, apply SharePoint permissions and understand the limits of web-part access filtering."
url: https://vitextra.com/en/support/kb/10500
language: en
published: 2026-11-07
modified: 2026-11-08
products:
  - "Policy Acknowledgement"
author: "Lidija Reising"
tags: ["Policy Acknowledgement roles", "role groups", "SharePoint permissions", "policy author", "auditor"]
---

# How to Configure Policy Acknowledgement Roles and Permissions

Assign role groups in Policy Admin, apply SharePoint permissions and understand the limits of web-part access filtering.

Product roles control which operations and views are available in Policy Acknowledgement. Policy Admin also applies role-based SharePoint permissions to the hub lists. Review both layers when designing access.

## Understand the roles

| Role | Main use in the web parts |
|---|---|
| **Product administrator** | Setup, settings, roles and administration; management and reporting access. |
| **Compliance manager** | Policies, campaigns, reports and exemptions across the product. |
| **Policy author** | Creating policies and managing policies owned by that author. |
| **Auditor** | Reporting and inspection without policy-management actions. |
| **Employee** | Personal assignments and policy content. |

Team-manager scope is derived from reporting relationships, with a setting for direct reports or the whole reporting branch. It is not a sixth role assignment in the Roles list. Ownership is stored on each policy; the author view filters policies by that owner.

## Assign groups

1. Open Policy Admin as a product administrator and select **Roles**.
2. Select Entra ID security groups or SharePoint groups belonging to the hub site for the required roles.
3. Keep at least one group for **Product administrator**.
4. Review the employee population and **Managers see all direct and indirect reports**.
5. Select **Save and apply permissions** and wait for synchronization to finish.

Use explicit employee groups when a precise access boundary is required. Although the interface offers **All licensed users**, the current role resolver treats that option as matching the current user without a license check. It must not be used as proof that access is restricted to licensed accounts.

![Product roles and assigned groups](https://static.vitextra.com/articles/10500/role-groups-en.png)
*Product roles and assigned groups*

## Understand what applying permissions changes

Synchronization grants site read access for role groups, breaks permission inheritance on the product lists and applies the list permission matrix. The account performing synchronization retains Full Control on those lists. Review the impact before applying this to an existing shared site.

In Direct mode, employees receive contribution rights on assignments and acknowledgement records. In Service mode, the employee entries in that matrix are read-only for those two lists. Employees retain contribution rights on questions. A user with several roles can receive the combined permissions of their groups.

❗ **Important**  
Policy-owner filtering and personal assignment filtering are implemented in the web parts. The permission matrix is list-level, not per-policy or per-employee isolation. Do not present these filters as a guarantee that users cannot access other records through SharePoint. A successful synchronization also does not prove that every pre-existing or elevated grant has been revoked.

## Separate audience, ownership and permission

These concepts answer different questions. A campaign audience decides who should receive a task. The policy owner determines responsibility and the author-filtered management view. A role enables product actions, while SharePoint permissions govern access to the stored records. Changing one does not automatically accomplish the others.

For example, assigning a policy to the finance department does not make its underlying list records private to finance. Moving a card to another owner changes which author should manage it, but is not a per-item permission transfer. Hiding a management page in portal navigation also does not revoke a user's existing list access.

Design role groups around responsibilities, then review effective data access for those groups. Where a person belongs to several groups, test that combined membership. A user with an author role and an administrative group may see or change much more than an author-only test account. Removing one membership may leave access through another group or an elevated site permission.

## Use a representative access test

| Test account | Application check | Additional access check |
|---|---|---|
| Administrator | Open Policy Admin and inspect the configured roles. | Confirm that expected administration remains available after synchronization. |
| Author | Open owned policies and verify the intended management actions. | Inspect actual list permissions rather than inferring isolation from the filtered view. |
| Auditor | Open the relevant report and download an allowed export. | Check whether actions that save a result or audit event require additional write access. |
| Employee | Open an assigned policy and submit a pilot confirmation. | Verify source access and the configured evidence-writing path. |
| Manager | Load the expected reporting team. | Check the effective data access and the scope behavior independently. |

Some apparently read-oriented actions also write data. For example, an integrity check saves its outcome, and a report export writes an audit event after generating the file. A read-only account can therefore see useful output and then encounter a write error. Investigate the specific failed operation before broadening its role.

## Maintain access after organizational changes

When an author changes jobs, review both group membership and ownership of the policies they maintained. When managers change, inspect directory relationships and stored assignment manager fields; a page reload does not rewrite historical assignments. When the recording mode changes, review the service and reapply the corresponding permission matrix.

Keep a short record of who applied permissions, which groups were intended and which representative tests passed. The synchronizing account retains Full Control, so assess it explicitly rather than assuming that a service-mode label means all human accounts are read-only. The whole-branch setting is likewise not enforced by the current Team Compliance selector; see [KB10530. Team Compliance: How to Monitor Your Team and Follow Up](https://vitextra.com/en/support/kb/10530) for the resulting reporting limitation.

## Verify and maintain access

Test with separate administrator, author, reporting and employee accounts. Confirm both the intended pages and the underlying list permissions. After changing the acknowledgement recording mode, run **Save and apply permissions** again and inspect the effective rights. See [KB10509. Policy Acknowledgement Data Storage: Direct and Service Modes](https://vitextra.com/en/support/kb/10509) for the recording modes and their limitations.