It is quite often that we want to limit access to data in the system for some users. Definitely not everyone in our company should see information about the candidates who sent us their CV, and absolutely no one outside the HR department should see how much money others. Access to full customer information is not always indicated, too. We do not want to share financial data of our customers with unauthorized people. The question is how to ensure an adequate level of access for our colleagues.
Customizing Dynamics 365 to fit our needs
The main role of the access control mechanism in the system is to provide users with access to the data at the right level so that they can effectively fulfill their professional duties. Access to the system is built on several levels and consists of:
- defining business units (BU),
- creating security roles,
- introducing field level security.
Business units
Business units are the basis of the structure of access and security in the system. Every system user has to belong to a business unit. Let’s assume that the main business unit in Dynamics 365 is our organization – Clip&Pin Holding Company. This is our default BU – it is created during system installation. Other BU can be created depending on our needs. So if there is a need to separate Clip and Pin, we create two subordinate business units: Clip BU and Pin BU. Each of these can have many subordinate units such as Marketing, Domestic Sales and Foreign Sales in the case of Clip and Marketing, Retail Sales and Wholesale Sales for Pin.
If we want to, we can do otherwise. For example, we can create Sales and Marketing business units directly under the Holding Company. The division of our company can reflect the structure within the company. Business units should allow us to limit access to data while supporting efficient flow of information in teams.
Security roles
The basic tool allowing us to assign access to the system is the configuration of security roles. In the simplest way, the role determines what scope of access to the system does the user have. In the OOTB system, without customizations and programming changes, there is a set of predefined roles that can be assigned to users. If necessary, we can adapt these roles to our needs.
Defining security roles can determine whether a user with a specific role has access to all the data (such as all Contacts and Accounts in the database), to the data available to everyone in the same business unit, or only to those he is assigned to.
Let’s take a few of our colleagues from Sales and Marketing Departments as an example.
Suppose we have the following roles in the system (among others):
| Role | Permissions |
| Vendor | I can see and edit my customers’ data, the sales opportunities I work on, and my offers and orders. I do not see my colleague’s data, cases or marketing campaign information. |
| Sales Director | I assign new customers to the appropriate vendors. I see clients of my subordinates, but I cannot edit their data. I do not see cases or marketing campaign information. |
| Marketing Specialist | I can create and edit marketing campaigns, create mailing lists. I cannot create offers or orders. I have no access to cases. |
| Marketing Director | I am responsible for budget planning for marketing campaigns, I delegate marketing campaigns for my subordinates. I cannot see customer service cases. |
| Customer Service | I see cases reported by customers. I can edit to ones assigned to me. I have access to customer information. I cannot create offers, orders or marketing campaigns. |
And they are assigned as shown:
Since both Kate and Gussie are Vendors, their customers, for whom they prepare and execute orders, are in the system. In addition, Gussie’s role is Sales Director. This means that she sees, which clients are assigned to Kate. She knows at what stage of the sales process is the offer prepared by Kate and what is the estimated sales revenue. Kate will not see what revenue her manager generates for the company.
In the case of Marketing Dept. the situation is a bit different. Nowell has the role of Marketing Director assigned to, but does not have the Marketing Specialist role. This means that he is not responsible for implementation of campaigns. His role is to create strategic plans and marketing tactics. Orville is the one responsible for marketing operations. He creates content of newsletters, develops marketing lists and organizes events promoting Clip&Pin.
When it comes to Patsy, he is the only one out of five who has access to customer service data. Employees from Sales and Marketing departments cannot see anything on service in the system. They don’t need to and therefore they don’t have the license for the Customer Service app. Similarly, Patsy doesn’t have a license for Sales app (that includes Marketing) and has no access to sales and marketing information. The only thing he sees are most frequently reported problems and cases of his customers.
Field level security
Each of our five employees has access to customer records (accounts and contacts) – a license for each app gives the user the right to access this data (of course, the decision whether a particular employee will see customer data – all or selected – depends on our internal policy). If we want to ensure safety of our data, especially sensitive data, we can set field security profiles.
This will prevent marketing staff from viewing your financial data not only in Dynamics 365. When exporting protected data to a Word or Excel file, the system checks the user’s permissions – if he cannot see the value in the field, the field in the exported file will be null.
Teams
Dynamics CRM users can be grouped not only into roles or business units, but also in teams. Division into teams is independent from the business unit. In general, teams are meant to give users access to the appropriate record in the system. They vary from the roles in the way that they allow us to manage people who currently have access to specific records easily.
If Kate is a vendor and has access to her retail customers, she works with them on her own. However, if there is a wholesale customer who announces a tender and she needs to provide complex documentation, with extended offer and references from other clients for him, Kate cannot prepare it herself. In such a situation, we should allow her to build a project team, consisting of Kate and Gussie, but also Gallen and Hector. All four will have access to the wholesale customer as long as they are part of the team. At the moment Gallen ends his job and gives Kate all the necessary referrals from clients, she will be able to decide to delete him from the team.
Data security
Properly defining roles and permissions in your system will help us better protect our data. We will ensure that the system complies with the company’s internal policies and legislative documents, such as General Data Protection Regulation. The process of assigning roles and permissions in the system is time-consuming, but necessary – especially in large organizations with an extended hierarchy. If we do not build proper structure in our system, we might often encounter problems with access to part of the system.
