Features and Terminology
It’s no surprise that both CRM platforms possess robust and comprehensive security features. Virtually all security models from the simplest to the most complex can be implemented and maintained. Each environment has a moderate learning curve and the setup of a production environment should not be undertaken by an administrator with minimal experience.
Don’t misunderstand me – this is not rocket science. In fact, both platforms provide fairly straightforward screens and options. The trick for the administrator migrating from one environment to the other is the deceptively similar terminology. In some cases the same term is has two completely different meanings and in other cases the behaviors of the “equivalent” features are radically different.
Another stumbling block is the mixing (or not) of sharing and permissions. Regardless of the platform, security is comprised of access to an entity/object and sharing involves access to the individual records within that entity/object. As we shall soon see, Dynamics CRM blends these two concepts whereas Salesforce keeps them separate. This post involves security settings only.
This series of security comparisons is by no means exhaustive. The primary goal is to provide an overview to the experienced administrator faced with migrating from one platform to the other.
Security Roles and Profiles
Salesforce.com objects are equivalent to Dynamics CRM entities. You will find standard and custom ones in both. The same questions need to be answered regardless of the platform: what can a particular user read, write, create and/or delete?
To answer these questions, a user must be assigned a …
Well, here’s where things get interesting. Both platforms ship with standard “user types” for lack of a better term. Dynamics CRM calls them security roles and Salesforce uses the term profiles.
Once a security role or profile is selected the CRUD (create, read, update, delete) permissions can be set on standard and custom objects.
To keep this as simple as possible (for this post, anyway) we will stick with the four basic permissions. As mentioned previously the Assign and Share properties in Dynamics CRM represent an attempt to simplify administration by placing security and sharing together. The Append and Append To options have no direct counterpart in Salesforce. Likewise, the View All and Modify All options in Salesforce have no equivalents in Dynamics CRM.
We are then left with four remaining attributes (read, create, write/edit and delete) and yet there are still differences. Salesforce provides a simple check box: either the user has permissions or she does not. Simple. With Dynamics CRM it is not a question of whether a user can edit records in the object; rather, it is a question of which records within an object may be touched. Once again, this is a mix of security and sharing.
If you coming from a Dynamics CRM world this may be disconcerting. Where is sharing set? If you are coming from a Salesforce world, seeing sharing mixed with security may be a cause of concern. Not to worry. These topics will be discussed in subsequent posts.
Permission Sets
Dynamics CRM administrators will encounter another difference between the platforms. Only one profile can be assigned to a Salesforce user whereas multiple security roles may be assigned to a Dynamics CRM user. Permission sets in Salesforce are essentially “extra” profiles. The goal of permission sets is to add rights to a limited group of users beyond what the base profile provides. Of course, you can do this by applying multiple security roles in Dynamics. The intention of permission sets is to reduce the number of security roles required and thus streamline security management.
Let’s assume that sales representatives are not allowed to delete accounts. However, there are two sales representatives that require this permission. In both platforms the least restrictive permission wins. This means that the base sales representative “type” cannot delete accounts. Next, a second entry is created that gives this extra functionality. A second security role is created in Dynamics CRM whereas a new permission set is created in Salesforce. The new security role and permission set is then assigned to the appropriate sales representatives.
So, what is the difference? Over time, the list of security roles in Dynamics CRM will grow considerably and will result in one big list. Salesforce permissions, on the other hand, are maintained in a separate list which keeps the list of profiles manageable. Is this significant? For complex implementations, perhaps. Otherwise, probably not.