When designing the security role structure for an organization in CRM it is common for people to create a role for each job title (or a rough equivalent). While there are indeed implementations that require such a security role structure, it is often overkill. To simplify the security model it is worth considering a ‘Base’ role.
Most organizations have a fair amount of privileges that are universal to their users. For example, all users can read all accounts, contacts, activities, and notes. And often all users can view all activities, but create and delete only at the user level. The ‘Base’ role would contain all such privileges and every (or at least most) users in the organization would get this role. Then leverage specialty roles for the one-off needs.
Example: Every user in an organization can view all cases but only the customer service users can create them. In addition to the Base role you would create a Customer Service role (new blank role) and provide the privileges for the Case entity as required.
The advantages to this approach are numerous but to highlight the big ones:
- Easier Maintenance – often a new business process is brought into CRM which requires a change to security. When this new functionality is available to all users the single Base role can be modified as opposed to changing each job title-specific role
- Quicker Up-Front Development – it’s way faster to create the Base role and test and troubleshoot it during initial implementation
- Simplified Analysis of Security Roles – sometimes a new position is added to an organization and the CRM administrator must slog through the different roles to determine which is the closest match for this new position. With the Base + Specialty system the analysis of the distinct specialty roles should be quite fast
Anecdotal Evidence: We recently migrated our own CRM environment from CRM 4.0 on premise to CRM 2011 Online. We did not have the Base role system in place but took the time to build it along with a few Specialty roles and assigned users accordingly as part of the migration. As expected on Day 1 (and 2, 3 and probably 4) users discovered that they couldn’t see this, or couldn’t do that. 90-95% of those items were addressed by a change to the single CEI-Base User role. Had we simply migrated our old security roles we would have had to make that same change to five or six roles…each time something was discovered.
by Customer Effective,
