Security Roles

Security Roles in Dynamics 365 define what users and teams can see and do. Good Security Role design helps the Department for Education (DfE) keep systems secure, consistent and easier to maintain.

What good Security Role design looks like

Security Roles should be simple, predictable and reusable. Create Security Role based on what users need to do, not on who they are or where they sit.

Do's

  • Create Security Roles based on job responsibilities, not teams or individuals.
  • Assign Security Role to teams where possible, rather than directly to users.
  • Use the minimum privileges needed for a role to do its job (principle of least privilege).
  • Use organisation‑level permissions only when absolutely necessary.
  • Create small add-on Security Roles where discrete ah-doc permissions are required such as permissions to import/export data.
  • Document what each Security Role is for, especially when created for a specific service.
  • Regularly review Security Role to ensure they still match how DfE services operate.

Don'ts

  • Do not create a new Security Role every time a small change is needed.
  • Do not assign users multiple overlapping Security Role without checking combined permissions.
  • Do not copy and rename Security Role without understanding what they contain.
  • Do not give every user high‑privilege permissions “just in case”.
  • Do not work around poor Business Unit design by giving users overly broad Security Role access.

Implications of how you design Security Roles

Security Role design affects:

  • Data access: Poorly scoped Security Roles can expose sensitive information to the wrong users.
  • Maintenance: Too many similar Security Roles make troubleshooting and updates difficult.
  • User experience: Over‑restricted permissions can break forms, views or app navigation.
  • Onboarding: Well‑designed Security Roles make it easy to give new users the right access quickly.

Examples

Example 1: Security Roles based on responsibility

A “Case Worker” Security Role may include permissions to create, update and assign case records, but only read access to related financial data.

Example 2: Using teams for flexible access

A data analyst working across several DfE service areas can gain access through membership of teams, rather than being given multiple high‑privilege roles.

Example 3: Avoiding unnecessary Security Roles

Instead of creating separate Security Roles for each policy area (for example, Early Years Case Worker and FE Case Worker), create one Case Worker role and manage data access using Business Units and/or teams.

Summary

Security Roles should be simple, clear and based on what users need to do. Assign Security Roles to teams where possible, avoid duplication, and review them regularly. Well‑designed roles support secure, scalable and maintainable Dynamics 365 services across DfE.