Salesforce vs Dynamics CRM: Security Model

To follow up on my popular Dynamics vs Salesforce: The War From the Trenches, I thought I’d dig a bit deeper into the security models. The models are considerably different and have their own strengths and weaknesses.

When deciding between Salesforce and Microsoft, the security model is perhaps the most important difference. When implementing CRM, who can see what is an enormous time suck and causes a lot of trouble. It’s the bad side of the 80-20 rule – this is the thing that’s 20% of your project but will consume 80% of your time.

Dynamics – Simple & Consistent, But Susceptible to Exceptions

In Dynamics, you have user roles, and hierarchy governed by something called Business Units. This means you can implement a clean org-chart security model very easily. The East Region VP sees everything in the New York and Atlanta branches, but nothing in San Francisco. And Johnny Sales Rep in New York can see only his own stuff but not the guy in the next cube’s.

The model starts and ends with ownership of a given record. It’s pretty straightforward: Johnny Sales Rep can edit Opportunities he owns but only view Opportunities he doesn’t, within his level in the hierarchy or below him.

To manage this you have a user role concept, which a user can have many of and are only additive. So if Johnny Sales Rep has Role A that allows him to edit a record, and Role B that wouldn’t allow him to edit it, he can edit it. Usually you can end up with a nice layered approach – a base role then a VP role that adds some capabilities, for example.

Dynamics Security Role Example

Dynamics’ security model has recently been improved to include a managerial/organizational hierarchy that reduces the need for Business Units.

The major weakness of this model is that it is focused on what’s at and below a given user in the tree, which makes it extraordinarily hard to operate cross-functionally. Say your customer GlobalCo is based in New York and is owned by Joe Sales Rep, so it rolls up to the North America unit. But GlobalCo has a branch in Johannesburg owned by Sally SuperSales, so that branch rolls up to your EMEA unit. The fact that they are in different branches makes it very hard for Sally to see what’s going on in New York. And if you have a strategic account manager that needs to see all branches of GlobalCo? Forget it. You’re left with workflows implementing automatic sharing, which isn’t reportable or traceable in any meaningful way, or even achievable using out-of-the-box tools. Addressing this stuff will consume your project budget.

This diagram illustrates what I mean.

It’s easy to create visibility within or below a branch of the hierarchy (shaded area). But crossing (the red line) is a disaster.

The good news is that sharing is applicable to almost anything – you can share individual Dashboards, Views, Reports, etc., in addition to records.

There is a Team concept that is marginally helpful here, but seems to always have one limitation that prevents you from using it.

This model is very clear-cut and it applies everywhere. Run a report, it’s relative to what you’re allowed to see, period.

Salesforce – Complicated, But More Crossfunctional

Salesforce’s model is conceptually complex but in the end is vastly more practical.

First, you need to decide if everyone should see everything. If so, you’re done. Otherwise, it includes three main components:

• Profiles, of which everyone has exactly one. This governs the base of what you can see. By default, everyone has permission to do whatever they want to records they own. If you want to prevent deleting Accounts, you need to take that away in the Profile.
• Permission Sets – like a Profile but users can have more than one; you can use this to grant permission in individual cases.
• Roles – this is a hierarchical role. Marketing Specialist rolls up to Marketing Director rolls up to Marketing VP.

On top of this you have automatic sharing. In my mind, this is the #1 advantage Salesforce has over Microsoft. You can do stuff like grant a Sales Operations team control over certain opportunities.

Autoshare to Sales Ops Example

You could think of other examples and applications – like maybe, grant an arbitrary group of product managers read-only access to any Opportunities lost to a certain competitor over features.

But this is messy as well. You have to know and keep track of:

• When there’s a conflict between a Profile and a Permission Set, the highest permission wins.
• When there’s a conflict between Sharing and a Profile, the lowest permission wins.
• And so on.

There’s no consistent, global rules, like how Microsoft’s user roles are always additive. For example, you could create a Dashboard that shows company-wide data and publish it to the whole company. You may or may not want the ability to do this. Or, Dashboards are only editable by the person who created them.

Also, SFDC formula fields, workflow and custom (Apex) code ignore field-level security. Microsoft always runs in the context of a given user and applies their security settings.

Like I said in my first blog – everything in Salesforce has an exception.

Feedback? Leave a comment or find me on Twitter: @BobHatcher.