Roles and Permissions

AccessPoint uses granular, tenant-configurable permissions rather than fixed job titles. On this page you build the roles your office uses — Coordinator, Reviewer, and so on — by granting individual permissions from a categorized catalog. This page defines what each role can do; assigning roles to people happens on Manage Users.

Where to Find It

Open Settings from the app toolbar and choose Roles & permissions in the Users & access group.

System Roles vs. Tenant Roles

• Administrator is the only built-in system role.
• Every other role — all coordinator-style roles — is defined by you. They are typically seeded from a jurisdiction pack and customized afterward.

Roles also come in two kinds, and the difference decides where they are granted:

• Assigned roles — Administrator and your tenant's own roles. An administrator grants these in Manage Users, optionally with an expiry date, which is useful for contractors and client users. They can also be held by a Microsoft Entra group (see below).
• Relationship roles — Custodian, Contributor, Reviewer, Advisor, and Reader. These are conferred automatically when someone is added to an assignment, a task, a review, or a case. They cannot be assigned in Manage Users.

Most offices work with roles matching these archetypes:

Your tenant's assigned-role names may differ from the archetypes above, but the permission behaviour is the same.

Privacy note: Custodians, Contributors, Advisors, and Readers work from sanitized content. The PII firewall strips the requestor's personal information out before it reaches them.

Building a Role

Group-Based Roles

A role can be held by a Microsoft Entra group as well as by named people, so joiners and leavers are handled by the group your directory team already maintains. Groups may hold Administrator, any custom global role and any case-matched role. Relationship roles (Custodian, Contributor, Reader, Advisor, Reviewer) are conferred per case and cannot be bound to a group; the server refuses the binding. The feature sits behind Settings > Features > Users and directory > Group-based roles (on by default).

Binding a group. Open the role (a new role must be saved first) and go to its Groups section. Pick the group in the Entra ID group picker: type part of its name and the picker searches your directory, labelling each hit Security group, Mail-enabled security group or Microsoft 365 group or distribution list. A security group is recommended, because administrators rather than the group's owners or members manage its membership. Optionally set Binding expires, then choose Add group. Each bound group shows how many members have been observed, any expiry, and who bound it. Remove group asks for confirmation; members lose the role at their next sign-in check, and roles granted to them directly are untouched. Every binding change is written to the audit log. Beneath the role list, Group-based roles > Group grace period (hours) (0 to 168, default 24) is the outage tolerance described below.

How it works:

• Membership is checked in real time, at sign-in — nothing is synced. AccessPoint asks Entra ID which of the bound groups the person belongs to (nested groups count) and caches the answer for five minutes, so a change in the directory takes effect within minutes.
• If Entra ID cannot be reached, AccessPoint keeps using the membership it last observed for the grace period and shows a warning in Setup. After the grace period, group-derived access fails closed. Access granted to a person by name is never affected.
• "Observed" members. A member is recorded the first time AccessPoint sees them hold the role, at their own sign-in. No members observed yet on a freshly bound group is expected until its members sign in. Pickers, approver lists and notices that reach role holders reach observed members only.
• Keep at least one Administrator by name. The last-administrator guard counts explicitly granted Administrators only, so an emptied or deleted group can never leave the tenant without one.
• Guests. Partner-organization guests sign in and hold roles like members. The SharePoint site must be shared with the guest, or the Teams guest app policy must allow the personal tab.

Permissions and restart. Resolving group membership needs the application permission GroupMember.Read.All on the managed identity, checked together with User.ReadBasic.All. It is granted from the Finish Setup page under the same default-on directory-reconciliation opt-out as User.Read.All, so a tenant that opted out cannot bind roles to groups. After granting, restart the App Service, because the identity's Graph token is cached. The group picker in Settings also needs the delegated GroupMember.Read.All scope declared by the SharePoint package; an existing installation must re-approve API access in the SharePoint admin center after updating.

Check group-based roles in Settings > Setup runs a live membership probe for your own account and reports whether the toggle is on, whether Graph is configured, whether the identity can read group membership and the state of the last membership check.

Case-Matched (Dynamic) Roles

A role can also be created as case-matched: its permissions apply only to the cases that match a rule you define. A rule can key on:

• a single-select custom field value — "Customer is Acme";
• a case type;
• a lifecycle stage — "all Closed requests".

Matching cases appear in the member's dashboards and open according to the permissions the role grants; everything else stays invisible. Before you save, the editor shows a live "currently matches N cases" count, so you can see the reach of a rule while you write it.

Rules only add access — they never remove it. A case-matched rule cannot take away access a member already holds through another role. Check a member's other roles before assuming the rule is what bounds them.

Typical uses:

• A service provider giving each client organization access to exactly its own cases.
• Junior staff who edit their own cases but can read the whole closed corpus for reference.
• A team granted access to a single case type.

If your case-matched members are guest users, remember that a guest should never also hold a standing global-view role. The rule bounds what AccessPoint shows them — not what a careless separate grant would.

Reporting for Case-Matched Members

Grant the permission Build reports on matching cases and the member gets the report builder, saved reports, and Ask AccessPoint over only the cases their rule matches — including exports and pinned tiles. Requestor PII fields are never offered to them, and they see only their own saved reports, not the team's shared ones.

Two things stay tenant-wide and are therefore not available to them: the ready-made report sections in the Reports panel, which are fixed organization-wide figures, and My Day and notifications.

The additive warning applies with force here. If the same person also holds an ordinary reporting permission through another role, that permission is not rule-bound and they will see whole-organization figures.

Senior Official (Accountable Owner)

Each case can name a senior official — the person accountable for the decisions taken on it, as distinct from the coordinator who does the work.

Naming someone gives them access to that case only. They can read it, see the requestor, open documents, and act on reviews, but they cannot edit or delete it. That is deliberate: it lets you make someone accountable for a single case — including an external adviser who is a guest in your tenant — without granting a role that would show them everything.

Cases they are accountable for that go overdue appear on their My Day, so oversight does not depend on somebody remembering to tell them.

Who can be named is controlled by the Act as senior official permission, which by itself grants no access to anything.

Permissions in Practice

Permissions gate what users see and do throughout the product. Examples that appear elsewhere in this documentation:

• View requestor PII — requestor names, emails, and other personal information are visible only to roles that carry this permission; custodians and contributors work from sanitized instructions without it.
• Act as senior official — controls who can be named as the accountable owner of a case. On its own it grants no access to anything.
• Build reports on matching cases — gives the members of a case-matched role reporting over their matching cases only.
• RequestorManage — required to edit requestor contacts and institutions.
• ConfigurationManage — lets a user share saved views tenant-wide and manage shared views.
• Place preservation holds — lets a person place holds on cases and use Preservation Holds in Settings. Someone who holds it without Manage configuration still gets the Settings gear, showing only the pages their permissions open.
• Manage training — for training leads: they see the Training settings row alone.
• Configure follow-up rules — lets a person manage follow-up rules.
• Correct the received date — in the Request group of every role editor (Administrator holds it); lets a person correct an active request's received date when the feature is switched on. Approving a correction that needs a second person takes Act as senior official instead, and never the same person who asked.
• Privacy program — View the privacy program, Manage the privacy program and Attest the privacy program. Attestation is not in the Privacy Officer role; grant it to the accountable senior official.
• *.configure permissions — some Settings groups (review workflows, privacy incident/assessment/complaint configuration) only appear when you hold the matching configure permission.

Roles and User Assignment

Roles do nothing until they are assigned. Use Manage Users to assign or remove roles per user. A user can hold more than one role — permissions are additive — and a last-admin guard prevents removing the final administrator, so you can never lock yourself out.