CRM systems are the most political of all enterprise software applications. This is partly because of the user community; sales and marketing play politics for a living. It's also due to the data in the system, as a single CRM table-the forecast-can make or break careers. Exactly who sees what, and when, is a key issue in organizations of any real size.
Every CRM system has a slightly different security model, but there are general principles that apply everywhere. This article focuses on the Salesforce.com access control and privilege model. It's complicated enough to be frequently misunderstood-which makes it a good example for illustrating key issues.
Core Privileges: Start With Exclusions, Then Add Exceptions
Salesforce security has several overlapping layers that focus first on exclusion, then on adding access as exceptions to the exclusion. In small systems, most of the filtering is turned off. This can lead to some nasty consequences, so larger organizations must use every filtering mechanism available to keep data quality up and compliance issues down.
The first exclusion filter is specified by the class of user, or profile, and is applied at the object (table) level: Is a given profile allowed to see an object at all, and, if so, what operations are generally allowed? In addition to create, read, update and delete, there are privileges to "change record owner," "be allowed to see any record of this object, even if you shouldn't otherwise be able to" and "execute certain classes."
The next level of filtering is at the column level. This enforces three levels of access: Hidden, read-only and read-write. Profiles also define system-wide privileges (for example, export report data), but most aren't object-specific and therefore not a big deal.
If you've created a bunch of customer fields and installed lots of applications in your CRM, this may mean you can set 1,000 attributes or more for each profile. Don't worry, it'll get more complicated soon enough.
To Avoid Broken Records, Sort Out Role Problems
The next layer of exclusion filtering is done by the user's role in the organization. Role hierarchy enforces a single Boolean attribute: Are you allowed to see an individual record, based on who owns the record? You can't see what your siblings (peers) or superiors own. If you can't see a record, it's literally invisible to you and any code that's executing under your user identity.
If you turn on roles in a system that wasn't using them before, all kinds of records just aren't there any more. Why? The system is now enforcing record ownership, and many of your records now owned by users who are inactive, who no longer work for the organization, who have no defined role or who have changed roles.
Sign up for MIS Asia eNewsletters.