Security Roles in Dynamics 365 CE

Security Roles are one of the most critical elements of the Dynamics 365 CE Security model. They Define what actions can perform and which data they can access.

Every user in Dynamics 365 CE must have at least one Security Role assigned. Without a role, the user cannot log in to the system.

What is a Security Role?

A security Role is a collection of privileges that define:

• The types of records a user can access (entities/tables).

• The actions they can perform on those records (privileges).

• The scope of their access (User, Business Unit, Parent: Child BU, Organization).

Security Roles do not grant access to specific records - instead, they define potential access. The actual data visible depends on:

• Ownership of the record.

• User’s Business Unit

• Record sharing

Key Components of a Security Role

Each Security Role contains a matrix of privileges per entity, covering:

Create → Create new records

Read → View existing records

Write → Update existing records

Delete → Remove records

Append → Link this record to another

Append to → Allow other records to link to this one

Assign → Change ownership of records

Share → Share record with other user/teams

Each privilege can be set at one of these access levels:

None → No Access

User → Records owned by the user

Business Unit → Records owned by the user’s BU

Parent: Child Business Units → Records owned in the user’s BU and all child BUs

Organization → All records across the organization

How Security Roles Work

1. Every user must have at least one Security Role.

2. A user can have mutliple Security Roles. The effective privileges are the union of all assigned roles.

3. Security Roles are assigned per Business Unit. If a user changes BU, their roles must be reassigned.

Out-of-the-box Roles:

Dynamics 365 CE includes standard roles such as:

• System Administrator: Full access to all data and system settings (cannot be restricted)

• System Customizer: Full customization access, limited data access.

• Salesperson: Typical role for CRM sales users.

• CSR: Typical role for customer service reps.

These roles are useful starting points but should be often be customized to meet organizational needs.

Common Pitfalls

• Overuse of System Administrator: Avoid assigning this role to normal users. It bypasses the security model entirely.

• Not using least privilege: Assign only the necessary privileges - too broad access increase risk.

• Unmanaged sprawl: Having too many overlapping roles leads to confusion and harder audits.

Best Practices

1. Follow least privilege principle - assign only the privileges required.

2. Modular design - create roles for functional areas (Sales, Service, Manager, Reporting).

3. Use Teams for additive access - use Owner Teams to grant extra privileges when needed.

4. Test access - regularly audit and verify what users actually see.

5. Document role definitions - maintain clear documentation for which roles exist and what they control.

6. Control role assignment - restrict who can assign powerful roles (especially System Administrator).