This article outlines the considerations when deciding whether to upgrade your security model and offers several rules of thumb for designing a simple security model.
Originally published in Q3 2017 D365UG/CRMUG Magazine
When upgrading to Microsoft Dynamics 365, it is a good idea to review the entire security model of your existing system with a holistic approach. There might be many reasons to upgrade your system. First, the old system might have been designed when all security features were not available. Second, the people on both the business and IT sides might have some pain points with the existing security model. Third, business evolves, and so do the security needs of the business. Old security models might not be the best design with respect to scalability, maintenance, and performance on Dynamics 365. Figure 1 below shows the timeline of security features in various Microsoft Dynamics CRM releases.
Dynamics 365 has many advanced security features; however, not all of them are required, and making a security model unnecessarily restrictive creates more problems. Try to keep the security as less restrictive as possible. A sign of an overly restrictive security model is this: Users are asking for access to some records in another business unit, and the administrator is manually sharing these records on an ad-hoc basis.
When getting requirements for security, rather than asking, “What records should a sales rep/regional manager/VP see?”, you should ask, “What records should a sales rep/regional manager/VP not access at any cost?” If they access the records, then what legal, financial, or management issues might arise? If there are no major issues, then it is possible that open access to every record works for the company. The security model should be used primarily for stopping the access, and displaying a subset of the records should be addressed by using system or personal views.
A newly added feature in Dynamics 365, “App creation”, gives the ability to change a site map, entities, and system views based on security roles. Taken together, you can create a personal experience for UI as well as data without having too many customizations or a complex security model.
Every company’s security needs are different; however, there are few rules of thumb for designing a simple security model. Let’s take a look at some scenarios.
Open Access is the Best
If Users don’t mind having access to all records, but want to see only their records, in the “My Accounts” view, keep the access open to all records. You will eliminate a lot of administrative requests later. In telemarketing sales companies, an open access policy might work. Users want their own accounts in a system view, but they still want to see other accounts because they want to respond to a call from outside their territory when other reps are not present. By utilizing the User or a team as the record owner and keeping access open to all records, Users can see their accounts in the “My Accounts” view and can access other accounts.
If stopping access to all accounts is not required, and Users work as a team in predefined territories, then you don’t need to define teams as owners of accounts. Just assign all accounts to a service account, and add Users as members of a territory displayed on the account. Then you just need to change the filters on “My Accounts” view as Territory where member of the territory is current User (see figure 2).
Business Units for Top-Level Management
Top-level management wants to access a large volume of data for reporting and analytics, but they do not interact with records that often. As such, business units can be used for their security needs. One key thing to remember: We are creating a 
security structure, so it might be significantly different from the organizational structure of a company. Business units are hard boundaries and should be as large as possible.
For example, in figure 3, for a global organization, it makes sense to segregate business by continents. Breaking them further down in countries should be done with caution. A sales rep speaking Italian might serve Italy as well as Italian-speaking parts of Switzerland, or a polyglot User might serve France and Italy. So breaking Europe further in separate countries, at least in this case, is not a good idea.
User/Team Ownership for Bottom-Level Management
Once business units are decided, try to solve the access issue for individual Users at the lowest level of the organizational chart of the company.
A company might have a business model of having single accounts served by one User, then assign that User as the owner of records. If the company has multiple Users accessing the same account, then make the team the owner of record, and add Users to that team.
Hierarchy for the Mid-Level Management
Hierarchy can be used for mid-level managers. Positional hierarchy should be used when a User is reporting to multiple managers. Manager hierarchy should be used when a User is reporting to a single manager. Positional hierarchy needs more maintenance by the administrator. For performance reasons, try to keep a hierarchy depth to three or lower.
Access Teams for Groups
Use of access teams might be needed when multiple Users serve a single Customer, and access needs to be restricted to selected Users.
Also known as team selling, this business model is more common in heavy equipment and the software products industry where a company sells multiple brands, and every brand requires a sales specialist. There is one account manager for every Customer as the point of contact, and other sales reps are responsible for specific brands. As shown in figure 4, in this scenario, make the account
manager the owner of the Customer and he/she can add other Users to access team members, when needed. This process of adding access to team members can also be automated with custom programming.
Record Sharing for Complexity
Scenarios discussed so far will work for a majority of companies. If these scenarios would not work, then individual record sharing should be considered. Sharing an account with a User or team gives the most granular level access to Users. However, this is the most resource-intensive security model. It can affect performance and needs very high maintenance from administrators.
For automation, you will need custom workflows that share/un-share records to a User or team and a mechanism to trigger them when territory or User assignment changes occur. Sharing to teams instead of Users and sharing to access teams instead of owner teams is better for performance.
If a corporation grows by mergers and acquisitions, then every operating company might have different territory definitions, sales reps, regional managers, and executives. However, they might want to collaborate in a single CRM system with a similar Customer base without claiming exclusive ownership for an account. In this case, you might have to evaluate every single record and share it manually or through automation to a desired team or User.
In conclusion, when in the process of upgrading to Dynamics 365, if security models become less restrictive, then it will save a lot of administrative hassle down the road, and it will improve performance.