Module 2

The Dynamics 365 Security Model

Module 2: Objectives
• Overview of the Dynamics 365 Security Model

• Create, Configure and Manage Security Roles

• Users / Teams & Security Roles

Purpose of the Security Model
 Control access to records
 Defines actions that users can take on records, based on who the user is, and
who owns the record.

 Control access to UI elements

 Forms, Dashboards, Business Process Flows

 Control access to features

 Mobile, Export to Excel, Print, etc.

 Simplify the user experience

 User interface will hide entities, records and features a user does not have the
privileges to use.
Security Roles Explained
 Define the permissions a user or team has
 Permissions defined by privileges and access levels
 All users must be assigned at least one security role

 Options for assigning security roles to users

 Modify the default roles before you assign them
 Create copies of the default roles as templates
 Create new Security Roles, adding the privileges you require –
usually only for roles with few privileges
Out of the Box Security Roles
 Dynamics 365 ships with default security roles already in the
system
 Represent common roles in organizations
 Can be modified to fit organization needs

 System administrator role cannot be modified

 At least one user must have this role

 Additional roles can be defined as needed

 Create a new role from scratch
 Copy an existing role and edit to fit needs

 Accessed through Settings > Security > Security Roles

Role-based security

• Within each role, security permissions are defined at the

following levels:
• Entity and record level. Every role includes the complete list of
actions that can be performed on each entity.
• Task level. Each role also includes yes/no access levels for certain
user and administrative tasks.
• Tasks include Print, Merge, Go Offline, and so on.
Privileges
• Privileges are the most basic security unit in Microsoft
Dynamics 365

• They define what actions a user can perform on each entity

in the system.

• Examples:
• Create Contacts
• Read Accounts
• Update Invoices
• Delete Cases
Security Roles: Entity Privileges
Privileges
Common privileges found in each role include:
Privilege Description
Create Can create records of the entity
Read Can read records of the entity
Write Can update data for records of the entity
Delete Can delete records of the entity
Append Can attach this entity to other records
Append To Can attach other records to this entity
Assign Can assign record ownership to other users or teams
Share Can share record with other users or teams
Append vs Append to
• Append: Indicates it can be attached to other records
• Example: Associate activities to other CRM records
• Append to: Indicates it can have other records attached to it
• Example: Account record can have cases, contacts, opportunities, etc.
• Application behavior is a combination of both
Append to Account Append to Account
No Append to on No append Documents Append Documents
Account

Nothing would display

in CRM since not
records can be
attached to it
Security Roles: Miscellaneous Privileges
Access Levels
• Access levels work in conjunction with Privileges.
• Privileges indicate what actions a user can perform on each entity
• Access levels define which records for that entity the user can perform actions upon

• Access levels are based on a combination of:

• record ownership
• business unit to which the user belongs
Access Levels
Organization
Root Business Unit

Sales Marketing Service

Parent: Child BU Access level for a specific

Support
privilege and record type
determines which records you
Business can perform that action on
Projects based on the location of each
Unit
records owner

User

None
 X
None
Organization
Root Business Unit

Sales Marketing Service

Parent: Child BU
Support

Business
Projects
Unit

User

None
User
Organization
Root Business Unit

Sales Marketing Service

Parent: Child BU Provides access for an entity &

Support privilege:
• Records owned by that user/team
• Records shared with the
Business user/team
Projects
Unit

User

None
Business Unit
Organization
Root Business Unit

Sales Marketing Service

Parent: Child BU Provides access for an entity &

Support privilege:
• User Access
• Records owned / shared with
Business users in the same business unit
Projects
Unit

User

None
Parent: Child BU
Organization
Root Business Unit

Sales Marketing Service

Parent: Child BU Provides access for an entity &

Support privilege:
• Business Unit
• Records owned / shared with
Business users in any BU subordinate to
Projects
Unit your BU

User

None
Organization
Organization
Root Business Unit

Sales Marketing Service

Parent: Child BU Provides access for an entity &

Support privilege:
• Entire organization
• No access restrictions
Business
Projects
Unit

User

None
Security Roles
• Roles and business units
• Each role must be assigned to a specific business unit.
Root Business
Social Mgr Role
Unit
• Roles created in a business unit are automatically inherited
by each of its “child” business units.
Social Mgr Role Sales
• New roles can be added to any business unit.
• Business units may each contain roles with the same name,
but permissions and access levels may be completely
Social Mgr Role Support
different.

• A user/team can only be assigned roles that belong to the

same business unit to which the user/team is assigned. Social Mgr Role Projects

• Moving a User to a new business Unit will remove all the

Security Roles associated with their account
• They will need new Security Roles from their new BU before they
can access Dynamics 365 again.
Assigning Security Roles
 For a single user or team
 Manage Roles, then select the roles
the user or team should have, and
deselect the roles they should no
longer have.

 For multiple users or

multiple teams
 Manage Roles, then select the roles
to add to the users or teams
 Existing roles are not shown, so you
cannot remove a role from multiple
users or teams this way
Users and Security Roles
 For a single user or team
 Manage Roles, then select the roles the user or team should have, and deselect the roles they
should no longer have.

 For multiple users or multiple teams

 Manage Roles, then select the roles to add to the users or teams
 Existing roles are not shown, so you cannot remove a role from multiple users or teams this
way
More on Users and BU’s
 When switching a user to a new BU:
 Switching a user to a new BU can take time if they own a lot of records. Consider doing it
after hours if possible
 All records they own will come with them. Users in their old BU may no longer have access to
those records if their security Role Access level was set to BU.
 May want to look at assigning records to teams rather than Individual users.
Teams & Security Roles
 Security Roles can be assigned to teams

 A Security Role is required for a team to own records

 A team must belong to only one Business Unit

 Team members can come from any Business Unit

 User and Team security roles will be combined and users

will be granted the least restrictive access level for that
record type and privilege.
Demo
Time
Multiple Security Roles
• Users/Teams can be assigned more than one role.

• Users/Teams assigned to more than one role use

a combination of privileges and access levels for
both roles.
• They are granted the least restrictive access level for
that record type and privilege.
Security Roles: Multiple Roles
Read Write Assign
Account
Security Role:
Opportunity
Baseline for all users
Case

Account
Security Role:
Opportunity
Sales Person
Case
Security Roles: Effect of Multiple Roles
User gets all the privileges of all their roles
Read Write Assign
Account
Security Role:
Opportunity
Baseline for all users
Case

Account
Effective Permissions: Opportunity
Sales Person Case
Security Roles: Layered Approach
Read Write Assign
Account
Security Role:
Opportunity
Baseline for all users
Case

Account
Security Role:
Opportunity
Sales Person
Case

Account
Security Role: Opportunity
Sales Manager Case
Security Roles: Effect of Multiple Roles
User gets all the privileges of all their roles Read Write Assign
Account
Security Role:
Opportunity
Baseline for all users
Case

Account
Effective Permissions: Opportunity
Sales Person Case

Account
Effective Permissions: Opportunity
Sales Manager Case
Security Roles: Non-Layered Approach
Read Write Assign
Account
Security Role:
Opportunity
Baseline for all users
Case

Account
Security Role: Opportunity
Sales Person

OR
Case

Account
Security Role: Opportunity
Sales Manager Case
Module Review
 The CRM security model is used to control access to data,
features, and UI elements
 Security Roles use a combination of privileges and access
levels to control access
 Users can be assign multiple security roles based on the job
requirements.