Role Based Security – What we already know.
Role based security within a CRM system enables the capability to show relevant system components based on the security roles assigned to a user. The obvious benefit of this is that two or more users belonging to different roles can login to the same organization and get a view specific to their individual needs. This is because based on assigned roles a user will only see what is deemed relevant to that particular role. As a user is assigned additional roles they will be able to see additional things. This is the sweet spot for a system because it is tailored to the various user communities of the system while allowing everyone to collaborate within the same system. In systems where role based security and/or visibility rules implemented via JavaScript/PBL are not used the forms will tend to have a larger amount of information on them that address multiple target audiences. As the number of fields or related data grids increase on a form that is not relevant to any particular user group increases so does user frustration, feelings of complexity and training efforts. Minimizing the amount of information adheres to Hick’s Law. Hick’s Law states the time takes for a person to make a decision as a result of the possible choices he or she has increases as the number of choices increases. If you’ve never seen Hick’s Law in practice try loading up a form with dozens of fields and then show it to a new groups of users and see what kind of response you get. What a good designer will be able to accomplish is to separate the relevant fields and components by user role into multiple role based forms and dashboards.
Where Role Based Security Falls Short
The unfortunate problem within CRM is that not all components are security enabled. What this means is as a system customizer you are unable to define visibility using the same security role mechanism that you can for forms and dashboards. I imagine the reason the decision was made by the product team not to implement role based security for views, charts and reports is that those components are inherently data driven. Since security roles already restrict what data users can see then these components already enforce security from a data perspective. The shortcoming of this design decision is that we don’t have an option of controlling the visibility of these components and in my opinion is a strategic flaw in the system.
Share Based Visibility Picks Up the Slack
This is where you can resort to another method of achieving the same tailored feel that help users not have to wade through non-relevant information. The method is to use share based component visibility. While forms and dashboards can be conditionally displayed using security roles the other common components can be conditionally displayed by sharing them. For example, I can create a chart and then share that component with other users and teams. Once shared the chart shows up in their list of available options. The net effect is the same as role based visibility just implemented using a different mechanism. If you’ve looked at a system more than a few departments you may typically find that the number of system views tends to grow quite large on common entities such as account and contact. The reason for this is that views are inherently global to an entity and while trying to accommodate multiple user groups these global views are created for each group but they all show up in the same list. If you are like some companies you may have even resorted to prefixing the view names with something like “Sales:” versus “Marketing:” to make it clear that a view or report is meant for a specific user group. The only real way to overcome this increasing growing list of views is to use share based views. While it is best to keep sharing within a system to a minimum I don’t see this as an abuse of the sharing mechanism because of its limited scope and application. Even still I would recommend sharing with teams if the components will be owned by a user like an admin instead of individual users as a better practice. Better still I would recommend assigning ownership of the shared components to the team that the target users will be a member of while I feel is appropriate. The only thing you’ll have to do is ensure that the team is assigned enough privileges so that it can own the shared components.
The Cons of Share Based Visibility
The downside of this is that the sharing is from a system user and as such is not easily transportable with the current solution transport technology. A user view in your development environment will not be saved in your solution export files nor is there an “easy” button to include that in a deployment script. I bring this up just to keep that solution in perspective of dev ops, source control and keeping with best practices. As of right now I don’t have a good answer for how you manage this without writing some code, but it is what it is for now.
The following shows components where visibility can be controlled role based versus only share based. Just keep in mind that effectively anything that can be user owned can be shared.
Role Based Components
- Forms
- Dashboards
Share Based Components
- Views
- Charts
- Reports
- Dashboards
To sum it up, there are ways to restrict the amount of information that is presented to the various user classes of your system. Tailoring the experience for the various user classes in a system not only reduces perceived complexity, but also promotes user acceptance and reduces the overall training effort. Role based security component visibility within CRM gets us part of the way there. Share based visibility can get you to the finish line as long as you implemented it strategically and factor it into your source control and deployment strategies.
