Whatever you do, don’t end up like the Death Star architect when designing the CRM Security model. Running with this analogy regarding a space-wizards movie in a galaxy far, far away, it’s important to avoid giving any pesky rebel user the equivalent of an open exhaust port into your CRM system.
Dynamics CRM is designed by default to be an open and collaborative system. However, there is always a need to restrict access to certain kinds of data depending on the user hierarchy and/or role in any organization. Luckily, CRM provides various security tools to get the job done; all you have to do is finalize the right mix of access and performance.
Avoid “security through obscurity”
A key theme when designing the CRM security model is to avoid the practice of security through obscurity. A simple example of this would be to hide access to certain records in the Views, but not consider that users may have access to restricted records elsewhere, like in Advanced Find. Users don’t need the Force to quickly discover loopholes in your model.
Always consider all the ramifications of adding customized access when addressing security needs that may fall outside of the default security configurations in Dynamics CRM. If there are known limitations in your design, be sure to clearly communicate them to stakeholders and highlight them in your documentation. Ideally, stakeholders may be open to adapting security requirements according to Dynamics CRM best practices.
Suss out all security requirements as early as possible
During the process of requirements gathering, it’s important that all security concerns should be surfaced and documented as early as possible in the SDLC. It may also be helpful to finalize reporting needs early on, since it would generally require a workable security model to display the right data according to user needs.
Introducing any changes to the security design of Dynamics CRM in a later stage of the project can guarantee a huge impact your delivery plan and budget. Avoid being a target for that managerial force choke!
Sample scenarios to help choose the right tool for your security model
As a rule of thumb, you can use the below scenarios to help determine the right security tool in CRM to use.
“I want our general users to have limited permissions to records, but give manager users more elevated permissions to the same records.”
Create separate Security Roles in CRM according to different user roles, which should help address this requirement.
“I want managers to view all the records owned by their direct employees, but not see records belonging to other managers and/or departments”
Luckily we have several options here. Each has its pros and cons, but all are generally safe options to address this scenario.
- A combination of Business Units and Security Roles can provide this setup. If managers and their users belong to their own separate business units (e.g. separated by departments), then they can be configured to have business unit access to records.
A new feature in CRM 2015 called Hierarchy can be used. There are two type of hierarchy configurations available: Managerial, and Positional. More documentation about this feature can be found here. The right configuration will largely depend on the organization’s hierarchy setup and needs. It’s important to note that hierarchy should be used in limited circumstances to prevent potential issues with performance, particularly systems with large userbases.- Last but not least, a combination of Business Units, Security Roles and Hierarchy may be what is needed to address more complex cases.
“I don’t want users to see CRM records originating from this specific region, unless they meet at least 4 of these 12 conditions, and it was generated on a Tuesday morning.”
This requirement isn’t very realistic, but it’s to provide an example where an organization believes that they must meet highly complex requirements about when users can and cannot access records. It’s likely that the out-of-the-box CRM security tools cannot easily meet these types of expectations as-is without some tricky code.
It is best in this case to demonstrate best practices for the system, and suggest workable alternatives that can be in line with their business rules. However, if the organization won’t budge on their complex security requirements, there are security options in CRM that I call “wildcards”. They are wildcards because they can help address the most complex requirements, but may also introduce unexpected performance results.
- In CRM it is possible to programmatically “share” a record with a user. The Sharing functionality bypasses any security model by directly granting a user access to a specific record. As many Dynamics CRM aficionados know, it is best to use this functionality very sparingly, since it may overtax the system and cause performance issues for users. However tempting this dark side may be, you should only employ this functionality if it can be proved that system performance can scale according to usage.
- A combination of Sharing and Teams may be an alternative strategy. Teams allow us to group users and assign access in bulk. Sharing a record to a Team record will be more efficient for the system than sharing the same record with multiple User records. This approach will help minimize the impact to the system performance, but should always be fully vetted and tested for scalability.
Security Modeling Tools Matrix
To condense most of the content above, I’ve provided my analysis of the different security tools available in CRM.
| Security Concept | Description | Implementation Details | Best Practice Scenario | Considerations |
| Business Units | Business units are groups of users, typically associated in a parent-child structure. | BU’s can be structured according to an organization’s regional or departmental model, depending on security needs. | Use Business Units in combination with Security Roles to design the “classic” CRM security model. | * Consider another security model if the organization needs to frequently modify the BU structure, as it also impacts Users and Security Role assignments. * Creating more than a few dozen Business Units may not be tenable for system performance and maintenance in the long term. |
| Role-based security | Security Roles can be configured to provide granular record access for a user to data. | Always use Security Roles to grant read, write, create, delete, and other access to specific type of records. | Use Security Roles in combination with Business Units to design the “classic” CRM security model. | * Do not overwrite out-of-the-box Security Roles as you may need to fall back on them for testing purposes. * Testing a user’s security role access is key to a successful implementation. |
| Record-based security | You can use record-based security to control user and team rights to perform actions on individual records. | A user or process may need to grant record access to another user/team that otherwise would not have access. | This feature is typically a manual process for users to grant other parties ad-hoc access to their record(s). In certain cases, the sharing of records can be programmatically implemented. | * This feature should be used sparingly on a record-by-record basis, as it could potentially impact system performance and bypasses the security model in place. It may be best to consider an alternate security model instead. |
| Team Security | A user’s access to data may be determined according to their Team assignment. | Teams let users across an organization collaborate and share information. | Teams make sense in scenarios where users are granted additional permissions to records associated with the Team. | * Determine whether a Team’s assigned Security Role will be the factor in determining the user’s access to records. * “Access Teams” in CRM provide additional security options, but note that an Access Team cannot own records. |
| Hierarchy Security | You can use the hierarchy security model for accessing hierarchical data. This additional security allows managers to access the records of their reports. | Two options are available: Manager hierarchy and the Position hierarchy. Use of one over the other depends on the organizational structure. | Best used in organizations where a BU/Security Role structure is not enough to address the need for a manager to access their employee’s records. | * The impact that hierarchy has to system performance is dependent on the total number of users. As a rule of thumb, use a hierarchy depth of 4 or less. * With the Manager hierarchy, a manager must be within the same business unit as the report, or in the parent business unit of the report’s business unit, to have access to the report’s data. The Position hierarchy allows data access across Business Units. |
| Field-level Security | Fields that contain sensitive information can be configured to have limited access according to the user’s role in the organization. | Fields with sensitive information, such as Social Security Numbers or bank account information, should be strictly controlled and limited to certain parties. | Record-level permissions are granted at the entity level, but you may have certain fields associated with an entity that contain data that is more sensitive than the other fields. | * Testing a user’s access to personally identifiable information is key to a successful implementation, especially if there are HIPAA considerations. |
Designing a security model in CRM can be quite the puzzle to think about, but is an essential step towards a successful implementation of Dynamics CRM. The challenge is coming up with a simple yet elegant design that can directly meet the organization’s needs. If done right, you can be confident your CRM system can easily make that Kessel Run in 12 parsecs.