The Analysis phase of a CRM Implementation starts with conducting a solution overview and detailed business process analysis. Once the processes are defined and aligned, the business requirements are gathered. In the past, I have found that there is little clarity on the security requirements during the Analysis phase. Having a two or a three day workshop would not necessarily ensure all the security requirements are covered and the solution is ready to be designed. Gathering the security requirements should begin towards the end of the Analysis phase and should be finalized by the middle of the Design phase.
This blog article explains an approach that has worked for me and my team in gathering the security requirements for a Dynamics CRM Implementation.
Business Units – Start with Business Units. They normally surface out of the business process analysis discussions. When you understand how the information flows across divisions in an organization and various roles responsible for the activities, you can start making a list of all the business units and roles you encounter as part of the business process flows.
The Business Units in CRM drives the Role-based security. Hence, it is important to map the business units in a hierarchy.
Role-Based Security – The Role-Based Security focuses on grouping a set of privileges together that describe the responsibilities or tasks that can be performed for a user. The business process analysis surfaces the most common roles performing various tasks within an organization. But there could be scenarios where the same role performs different tasks. In this scenario, it is always a best practice to create them as two separate security roles in CRM.
Once the list of security roles are finalized, they need to be revisited towards the end of the Analysis phase to imbue them with more information. At this stage, it is important to have a security matrix with the list of all the roles mapped against privileges (Create, Read, Update, Delete, Assign, Share) and functions such as export to an excel, print, approve a budget, closing a case etc. These functions could be the exceptions which are found during the functional requirements gathering and those which cannot be accommodated through the out of the box security role privileges in CRM.
Record-Based Security– Now that you have the business unit hierarchy, base security roles and the privileges against each entity and function, the details around the record-based security will have to be captured. You will have to focus on the access levels for each of the CRUDAS privileges.
Teams – Setting up Teams in CRM are derived from the functional requirements captured, the business unit hierarchy to be setup and the security roles to be configured. If you have a requirement where a group of users across various business units need to collaborate on a record, then you create teams in CRM and share the records with the team. But if you do not know ahead of time how many teams you need to create, there is a new feature in CRM 2013 called the ‘Access Teams’ which could just be the answer. An access team doesn’t have any security roles assigned to the team and doesn’t own any records. Instead, the records are shared with the access team and team is granted access rights on the records, such as Read, Write and Delete.
Field Level Security– The final bit of security requirement is to capture the field level security requirements. Field level security restricts field access to specified users and teams. Typically, the requirements for field level security are driven by the functional requirements. The field level security discussions can happen after the business unit structure, base security roles and access rights have been configured, as you would already know which role does what, and how.