Dynamics CRM vs. Salesforce: Customization. Part1 - Security model
You can find over the web a lot of articles or user reviews with comparing Dynamics CRM and Salesforce. But usually they do not cover (or do it a few words) the question of customizing this systems. This option is “invisible” for regular CRM users but might be extremуly meaningful when you make a decision what CRM system your are going to use. So, lets dive deep in details to see which abilities provide both systems, discover their strengths and weaknesses.
I am going to include into the comparison list of questions below and will try to provide general description for them:
- Security model
- Dashboards and Reports
- Integration with services
First of all I describe entities I am going to operate with (please note that analogies I am drawing between CRM and Salesforce objects not 100% but very close):
- User is person who can log in into CRM organization
- Business Unit(in Dynamics CRM)/ Role (in Salesforce) corresponds to department where work the person (but not always in real life). Business units and roles may be structured hierarchically. Each has only one parent but may have many children. Each user can be assigned only to the one business unit.
- Role (in Dynamics CRM)/ Profile (in Salesforce) declares privileges per entity (e.g. Read privilege for Account)
Dynamics CRM and Salesforce both have multiple levels of security configuration that guarantee visibility of different information:
- Organization access level
- Entity/Object level
- Record level
- Field level
Organization level represents the access to the entire organization (login into the system). Salesforce have some outh-of-the box configuration for this:
|Setup login hours||No*||Yes|
|Setup IP ranges||No*||Yes|
|*- it may be done through plugins|
Entity/Object access level says us what privileges to which type of entity user have (may also say which parts of application user will see and some other things) and mainly speaking Roles/Profiles are responded for that. But here we have two different approaches.
In the Dynamics CRM each entity has a range of standard privileges: Read, Write, Edit, Create, Assign (change the owner), Share (grant privileges for record to another user) that can be granted on different levels: User, Business Unit, Parent (BU and children) and Organization. E.g. for role “Sales Assistant” we can set Account visibility (Read) on User level - it means that user with this role can view only his own accounts (until somebody shares with him manually).
In Salesforce profiles contains which access owner have to the record operation (Create, Read, Edit, Delete, View All, Modify All) across the entire organization and which access have users with this role to his and other users records.
For the first look it seems that Salesforce have some limits in its security model and do not give us ability to manage visibility level on business unit level but this is only for the first. Salesforce can to that with sharing rules and permission sets.
|Assign multiple roles/profiles to user/team||Yes||No|
|Includes out-of-the-box security roles/profiles||Yes||Yes|
|Standard security roles/profiles||Yes||No|
|Manage application parts using security roles/profiles||Yes||Yes|
|Manage CRUD operations per entity||Yes||Yes|
|Share by criteria (as out-of-the-box feature)||No||Yes|
In Dynamics CRM you have ability to directly edit standard roles but sometimes it leads to creating invalid roles (user can not do anything because some base privileges were removed). We should do it carefully. Salesforce don’t have this problem.
Record level access is about giving privileges to another user for particular record. In both systems this problem solved through manual sharing or managed sharing (provides developers ability to share the records through system extensions)
Field level access says us about visibility of particular field in the entity. In the Dynamics CRM it can be set for users or teams. In Salesforce it is configured for security profiles and I found this way more natural than in Dynamics CRM (to be honest I always could not understand why we have implementation that requires duplicate team for security role).
|Field level security||Yes (user/team based)||Yes (profile based)|
Although both systems have similar capabilities in security configuration Salesforce makes it easier for developers and system administrators . A lot of requirements that in Dynamics CRM can be achieved only with developers forces in Salesforce can be done by system administrator with some clicks (e.g. sharing by criteria). It also allows to avoid some mistakes during security roles/profiles configuration. So, when you have a complex system with multilevel hierarchy and criteria based sharing rules Salesforce security model in many cases let you save time and
You will achieve much better result if will concentrate more on your product and team and provide solving these problems to out great specialists. Centaurea's team has large experience with CRM systems and we are ready to offer you our services: CRM development, consulting. We are looking forward to start working with you!
P.S. We are glad to receive a feedback from you. If you have noticed any mistakes in the article or have suggestions about it please let us know.