Terminator: CRM Judgment Day

A common theme in science fiction is technology run amuck.  Whether it’s the rise of a sentient network in Terminator or mutating weapons of war in Screamer, there seems to be some basic, primal fear of being destroyed by the works of our own hands.  And it’s probably with good reason.

In Salesforce, and in most or all other CRM systems, there is the concept of a sharing rule.  These rules extend permissions and visibility beyond what a user has by her inherent role in the hierarchy and what is provided by her profile.  For example, perhaps Ming might be restricted by her role to see only accounts in Singapore and by her profile to a read only status.  Depending on the CRM system, a sharing rule could let her see accounts in Germany, France, and Canada, as well as giving her write permissions.  Sharing rules are very powerful, extremely useful, and remarkably dangerous.

Why dangerous?  First, they are complex.  Much like introducing rabbits to Australia the unintended consequences are not immediately obvious and can be hard to combat.  Anything that modifies the organic structure of a system’s architecture is complicated and complicated things are prone to error.  Are you absolutely, positively, certain the rule you are about to roll out in production won’t expose confidential data or lay your system open to an angry sales person?  You did test it in sandbox, right?

Second, they are persistent.  Like the sorcerer's apprentice, once set in motion, they will continue doing their job forever.  Possibly long after the need is gone and the administrator who created it has moved on or has forgotten about it.

Third, they are difficult to document.  Being complex and dealing with the relationships of a fluid enterprise, what seems clear and understandable to you today, may mean little to your successor, trying to unravel the mess, five years down the pike.

Should we avoid sharing rules?  No, of course not.  What we have to commit to do without fail is to:

1.  Use them only when there is no other choice and then grant as limited powers as is possible.

2.  Document them in painstaking detail.  Assume that when the documentation will be read, you are dead and the reader is not particularly bright.

3.  Review them at least once a year and make sure they are still needed, accurately working, and that the documentation is up to date.

Use sharing rules, but don’t leave a mess for the future!