Understanding Security Roles in Dynamics 365: Privileges, Access Levels, with examples
Security roles in Dynamics 365 ensure that the right people have access to the right data and actions. By combining privileges and access levels, organizations can define what users can do and how far their access extends within the organization. This blog will cover privileges, access levels, and their practical applications, along with examples.
What Are Privileges in Dynamics 365?
Privileges are the core of the Dynamics 365 security model. They define the actions users can perform on records. Privileges are predefined and cannot be created or deleted, but they can be adjusted as per the organization’s needs.
Types of Privileges
- Create: Enables users to create new records.
Example: A sales rep creates a new lead. - Read: Allows users to view records.
Example: A customer service agent reads a case. - Write: Permits users to update existing records.
Example: A manager updates an opportunity status. - Delete: Grants permission to delete records permanently.
Example: A user deletes obsolete campaign data. - Append: Enables associating a record with another record.
Example: Linking a contact to an account. - Append To: Allows associating other records with the current record.
Example: Adding opportunities under an account. - Assign: Permits changing the ownership of a record.
Example: A lead is assigned to another team member. - Share: Lets users share records with others.
Example: A project is shared with a colleague for collaboration.
Access Levels in Dynamics 365
Access levels define the scope within the organization where users can apply their privileges. Each privilege is associated with one of the following access levels:
1. Organization
- Users can access all records within the organization, regardless of their business unit.
- This level also includes Parent: Child Business Unit, Business Unit, and User access levels.
- Use Case: Typically reserved for system administrators or senior managers with overarching authority.
- Example: A CEO accessing sales data across the entire organization.
2. Parent: Child Business Unit
- Users can access records in their business unit and all its subordinate units.
- Includes Business Unit and User access levels.
- Use Case: Best suited for regional managers overseeing multiple business units.
- Example: A regional sales manager reviews performance data for all teams in their region.
3. Business Unit
- Users can access records within their specific business unit.
- Includes User access level.
- Use Case: Ideal for managers responsible for a single business unit.
- Example: A department head managing resources within their business unit.
4. User
- Users can access only their own records, those shared with them, or those owned by a team they belong to.
- Use Case: Common for sales representatives or customer service agents.
- Example: A salesperson tracks their assigned leads.
5. None
- No access is granted.
- Use Case: Used for restricting specific privileges for certain roles.
- Example: Preventing interns from deleting records.
Configuring Member Privileges in Security Roles
When creating or editing security roles, you can define privileges for teams and individual users:
Team Privileges Only
- Privileges are granted through team membership.
- Team members without individual privileges can access team-owned records.
- Example: A marketing team member accesses campaigns owned by the team.
Direct User Access (Default Setting)
- Privileges are assigned directly to users.
- Users can access records they create or own.
- Example: A support agent accesses cases they are assigned to.
- Sachin Sen
https://www.linkedin.com/in/sachin-sen-5b48091b9/
