CRM security management

CRM security management is critical to creating and maintaining an effective CRM system. Any CRM system worth the name will offer you powerful tools to control access and privileges within your records, and Microsoft Dynamics 365 for Sales is no exception.

In this article, I will introduce the core concepts behind the Microsoft Dynamics CRM security management model.

This is by no means an exhaustive guide. Were I to write an exhaustive guide to security in one post, it would be exhausting for all of us!

Instead, this article focuses on the basics, and offers a jumping-off point from which you can take deeper dives into specific aspects of Dynamics 365 CRM security management.

To that end, I’ve divided this article into three parts: 1.) defining your organization in CRM, 2.) understanding access rights and privileges, and 3.) the three most common layers of Dynamics CRM security.

 

Part 1: Organization

Microsoft Dynamics 365 CRM divides your organization into business units, teams, and individual users, much like most businesses do for their day-to-day operations.

When you create an organization in CRM, Dynamics automatically sets up a root business unit: this is your organization as a whole, and it cannot be deleted or disabled (though you can rename it).

Once you have your root business unit, you can create other business units, teams, and user roles to mirror your organizational divisions and hierarchies.

These organizational elements are the building blocks of your CRM security settings.

 

Business Units

Beneath your root business unit, you can create additional business units to represent the important divisions and departments within your business.

For example, you can create business units for your sales, marketing, customer service, and accounting departments. If your company is organized by region or specific location, you can break those business units down further.

When you create a new business unit, you must specify the parent unit. Your highest level will be your root business unit, but you can create multiple child business units beneath it, and then multiple child business units beneath those, and so on. Essentially, you can re-create your org chart in Dynamics 365 for Sales.

Your teams and users will be associated with one business unit each, so build your business units with that in mind!

You can also set some of your security parameters by business unit if you so choose.

 

Teams

Owner teams and access teams allow you to share and collaborate on records across business units. Unlike business units, a user can be assigned to as many teams as you wish. A user and their teams do not all need to be assigned to the same business unit.

You will need to set permissions and access levels (see Part 2) for each of your teams. Keep in mind that users gain all the rights granted to them by all the teams they are assigned to.

When you create a business unit, Dynamics will automatically create a default team for that unit. But just like with business units, you can add additional teams to your organization.

For example, you can create sales or service teams within larger business units, or teams dedicated to specific tasks or events.

 

Users

Users represent the members of your organization in CRM. Each user must be assigned to a single business unit, but can also be assigned to one or more teams.

Each user must be assigned a role, which is important for role-based security (more on that in Part 3).

 

Part 2: Access

Once you have built your organization in Dynamics 365, you can use that structure to add rights and restrictions at the unit, team, and user levels.

Microsoft Dynamics 365 for Sales uses privileges and permission levels to set those rights and restrictions.

Basically, a privilege represents something a user can (or cannot) do with a record. An access level represents which and how many records that user can exercise those privileges on.

 

Privileges

Dynamics 365 uses 8 basic record-level privileges:

1.) Create enables a user to make a new record.
2.) Read enables a user to open and view a record.
3.) Write enables a user to make changes to a record.
4.) Delete enables a user to permanently erase a record.
5.) Append enables a user to associate another record to the current record.
6.) Append to enables a user to associate the current record to another record.
7.) Assign enables a user to give ownership of a record to another user.
8.) Share enables a user to grant access to a record to another user.

 

Access levels

Dynamics 365 uses 5 access levels:

Global allows access to all of an organization’s records.
Deep allows access to all records in their business unit and in subordinate units.
Local allows access to all records in their business unit.
Basic allows access to records they own or that are shared with them or their teams.
None allows no access to records.

Microsoft recommends a few basic best practices for Dynamics CRM access levels:

 

Part 3: Security

Microsoft Dynamics CRM security management can appear quite complicated at first. But it’s useful to break it down into three parts: role-based security, record-based security, and field-level security:

Role-based security controls access by entity type.
Record-based security controls access to individual records.
Field-level security controls access to specific fields.

 

Role-based security

Role-based security enables you to restrict or allow access to record types by entity.

When you use role-based security in Dynamics 365, you create roles with specific privileges and access levels, then assign those roles to your users and/or teams.

You can also use default security roles provided by Microsoft. Microsoft Dynamics 365 for Sales comes with 14 pre-built roles:

1.) CEO-Business Manager
2.) CSR Manager
3.) Customer Service Representative (CSR)
4.) Delegate
5.) Marketing Manager
6.) Marketing Professional
7.) Sales Manager
8.) Salesperson
9.) Schedule Manager
10.) Scheduler
11.) Support User
12.) System Administrator
13.) System Customizer
14.) Vice President of Marketing
15.) Vice President of Sales

You can customize existing roles or create new roles, but we strongly recommend you avoid changing the out-of-the-box security roles.

Instead, we recommend you copy an existing security role and modify it to fit your needs.

 

Record-based security

You can also set security for individual records by business unit, team, or role. This enables you to restrict or allow access to individual records in ways not covered by (or contrary to) your role-based rules.

For example, if your salespeople would normally only see lead records they own, but you want your sales team to be able to work on some leads together, your sales manager could use record-based security to give users access to those lead records.

Keep in mind, though, that record-level access rights apply after privileges. So if you share read access to a record with a user who does not have any read privileges for that record type, the user will still be unable to read the record.

 

Field-level security

Even more granular than record-based security, field-level security enables you to restrict or allow access to specific fields within your records.

This is extremely useful in ensuring data integrity for records used by multiple business units.

For example, if you have a credit approval field in your account records, you probably want to restrict write access to members of your accounting department. Field-level security allows you to do so.

 

Ready for more on Dynamics CRM security?

The QuantaCRM crew offers you top tips for keeping your CRM security tip top!

 

 

Was this post helpful? Enjoyable? Do you have feedback or additional questions? Let us know in the comments, or contact us directly. We’re here to help!