Monthly Archives: March 2016

Salesforce vs Dynamics CRM: Security Model

Published by:

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 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

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.

Dynamics vs Salesforce: The War From the Trenches

Published by:

I’ve been pretty deep in Salesforce.com (SFDC) the last few weeks. There are a lot of articles out there that compare the two solutions at a CIO level, so I thought I’d take a moment to outline some of the more nitty-gritty pros and cons.

2491924-mortal+kombat+2+game+playHere are some of the key differences in my mind.

Where Salesforce Wins

  • VisualForce makes for a much more customizable interface. You’re not limited to dropping fields on a form – you can make a custom webpage part of your process. Custom buttons too. So what you see on the screen is not limited to drag and drop fields.
  • Salesforce’s implementation of Apex unit testing is outstanding. You can create test classes and you must run them before you can promote code into an instance. It’s brilliant and makes you a lot more confident deploying code.
  • Salesforce has a lot of native functionality that Microsoft still hasn’t gotten to. Lead assignment rules, approval processes, autonumbering, rich text text areas, dependent picklists, and multiselect picklists come to mind. Formula fields in SFDC make life a lot easier too.
  • Login as. OMG, login as. Microsoft, if you can hear me, you must allow admins to login as other users and see what they’re seeing.
  • Salesforce’s autosharing rules by role are very helpful. It is very hard and time-consuming to share across the organizational hierarchy in Dynamics. If you have crossfunctional roles like strategic account managers, this is huge. See my follow-up post that addresses this in detail.

Where Microsoft Wins

  • Salesforce has no equivalent to Advanced Find and how I miss it so.
  • Dynamics’ workflow concept is much more robust, and the equivalent things in Salesforce are kind of scattershot. SFDC’s workflow rules only do a small set of things. For example, if you want to copy a Lookup value from a parent record onto a child record it’s a 60 second workflow in Dynamics. In Salesforce, it’s code. A lot of code. (And I needed to copy the value because Salesforce email templates don’t let you access related records as recipients.)
    • Edit: Salesforce has a tool called Process Builder, which is a visual workflow tool that on the surface is like Microsoft’s. However, it’s been out for a while now and has very low adoption. As I understand it, this is due to weak “bulkification” – the need in Salesforce to do everything in a batch process (i.e., update 100 records with one statement rather than execute 100 statements). Bulkification is a persistent concern with everything in Salesforce. So the processes tend to fail when performing high volume processing such as imports.
  • I miss Microsoft’s idiot-proof data import function.
  • It feels like everything in Salesforce is an exception. Want to require a field at the database level? No problem.. unless it’s a picklist. Want to map a field to a child record? No problem.. unless it’s a Lookup. Role hierarchy can be disabled but only for custom objects/entities. Dynamics is much more of a UI on top of a relational database, which means it’s a lot less restrictive.
  • Microsoft has a more complete vision for first-in, first-out queues. There is an intersection entity that enables users to view and claim work. Salesforce’s Queue is essentially a Dynamics Team – basically the record is owned by more than one person.

Other Thoughts

STUART SAVES HIS FAMILY, Al Franken, 1995.

  • Settings/Config search in Salesforce is great but it’s hard to switch between two things, like the config page for an object (entity) and a child object (entity). Microsoft’s tree structure is harder to find things, easier to toggle.
  • Microsoft’s picklist implementation is far superior, using a database value and a text label that’s swapped out at runtime. Salesforce picklist values are stored as text, and the only way to refer to picklist values in code is by their labels, so you basically can’t change picklist values once they’re set (although there is a global replace function for picklist values, but that won’t help your code.)
  • Salesforce’s config screens are maddening sometimes, how lists are not sortable or searchable.
  • Microsoft’s browser compatibility is not great. I’ve tried it on Windows with Chrome, IE, Edge, and Firefox and the one that works best is… Firefox? And on Mac only Safari is supported.. poorly.
  • Microsoft’s cascading rules are more flexible than Salesforce’s Parent-Child and Lookup relationships. Salesforce doesn’t natively support N:N either.
  • Salesforce has a lot of development tools, and so far I’ve tried Sublime/MavensMate, Cloud9, and the native Developer Console. None of them are simultaneously reliable and a good development experience. Visual Studio isn’t great either, and it’s heavy and expensive, but it’s reliable, and you can actually set breakpoints and look into objects at runtime. And you don’t get [expletive]blocked by multitenant hiccups like “Admin Operation Already in Progress.”
  • Salesforce’s Custom Settings make it much easier to manage things like the email address your custom code sends to. In Microsoft you can do it with a custom entity, but why should you have to?
  • I’ll say this again: how Microsoft doesn’t have multi-select and dependent picklists by now is beyond me.
  • Support for client side scripting on Salesforce screens (layouts) is poor.

I’ll post again when I have more to ramble about. Feel free to leave a comment to clarify or correct me.