CRM On Demand has evolved over the years since Robert and I started working with it to allow many different ways of defining data access. The impact of each, and the combination of them, can be a bit confusing to the uninitiated. In this podcast, we take a tour of the various options available and some things to consider for each.

When we talk about data access, we’re talking about the mechanisms used to segment and protect data and allow users to effectively work with data that makes sense to them, as well as collaborate with others.

Back in the early days with CRM On Demand we only had a few options when it came to data access controls. Those were Manager Visibility and Account Teams. We’ve come a ways since then.

This is a topic that comes up a lot in our work with customers. There are a lot of misunderstandings or incomplete understandings about what controls are available, what they do and how they work together. This is relevant to more than just data security (who can see what) but is also integral to process design. Users who have a role within a process must have the right access at the right time in order to perform their work.

Let’s start with Manager Visibility.

This is visibility based on user hierarchy (Reports To), enabled at Company level. It grants “Owner” access to managers up the chain.

Pros: Simple, works well for many implementations. Most small to mid size companies start with this. It’s very straightforward to implement – just a checkbox on the Company Profile. Then it’s just a matter of making sure the user hierarchy is in place correctly.

Cons: Too simple for most companies. Once you get past the most basic organizational structure, MV starts to break down. For example, a customer I’ve worked with has, on it’s face, a very simple hierarchical sales structure. Sales people, within a branch, within a territory, rolling up to a division, VP, etc. But a closer look revealed that those reps in the branch rely on product specialists – sometime several of them. And each branch has admin support that needs access to deals in the branch. Suddenly it wasn’t so simple.

Another strike against MV is performance at certain levels. Specifically over 5 levels in the hierarchy things may start to slow down for users at the top. When you approach that size, you should consider another access scheme or “all access” for those users.

Moving on to Teams

Teams allow discrete controls over who can see a record and some discretion over the level of access (read, edit, etc). They enables ad hoc collaboration among users. Through Team Assignment, they can be automated, though only with ownership changes. Account Teams allow you to quickly add users to an Account and give them access to all the related records (Opportunities, Contacts).

Opportunity and Contact teams work the same, but on the discrete child records, whereas account team members can see all (or none) of the child records.

Pros: Great for ad hoc collaboration, adding individuals to small teams. Again, can be automated to some degree in the system and can be managed through web services.

Cons: Performance with large teams (more than a few dozen members on a single account) can really slows down access. Can be unwieldy to manage since assignment rules only Add team members, and do not Remove them.

There have been complaints about the level of control Teams allow and confusion over how it works, especially with regard to related records. We’ll get to some of this in our next podcast. Suffice it to say that Teams can get a bit unwieldy when you need really refined access at all record levels.

Those Darn Groups

Groups were introduced to allow for collaboration within CRM OD. It essentially creates a static Team – when one member of a group is added to an Account, all members of the Group are added (enabled through Default Group Assignment in company profile). The other use of Groups is for Calendar sharing. Group members can see one another’s calendar for purposes of collaboration.

Pros: Really I don’t like to promote this feature. It has some usefulness if what was described is exactly what you need.

Cons: The biggest drawback is that it is very rigid. Users cannot belong to more than one Group. Right away that makes this a non-starter for a number of companies. Generally this whole feature has been subsumed by Books.

The Amazing Book of Business

Group your records and users into flexible, hierarchical containers. Control detailed rights using Access Profiles, and automate it all via workflow.

Books can reflect a territory structure, organizational structure, overlays, etc. Records are individually assigned to books manually or through automated workflow. Users are assigned to books – one or many. And there are no restrictions on cross-listing of records or users among books. Books can be hierarchical or just a flat structure or some combination.

Record types (accounts, contacts, etc) are independently assigned to Books – that is, when you put an account in a book, the related records don’t just come along automatically. So you can really define a very detailed level of access control.

Pros: Books answer a lot of the drawbacks seen in Teams, Groups and mgr visibility. Book assignment can be totally controlled (add / remove / replace) via workflow and list management. Web services support was recently introduced, so now anything you couldn’t do via workflow could be done with custom programming.

Nowadays, when we run into a tough customer situation, Books are more often than not a part of the solution.

Cons: Some inconsistencies still exist between UI and analytics. Look-in can be a paradigm shift for users as it may require them to select a specific book to find what they want. Performance peaks at around 30,000 records per book. So really big books are something to avoid.

Ever Considered Delegation?

Just a quick word on this. Probably one of the least used features, at least among the customers I’ve worked with. But it actually provides a nice way for a user to “grant” his access rights to another user. Works well for owner / mv or team based access but doesn’t pass along Books and doesn’t apply in Analytics.

Don’t Forget Roles

There are important access controls within the Role Definition that can be applied. One to look out for is the “Read All Records” checkbox.

This is kind of a brute-force means of applying access. When setting up a Role you can specify “Has Access”, “Can Create” and “Read All Records”. You can completely shut someone down or open it wide for a role. But this area doesn’t give you a lot of finer control over what they can do.

 So you need Access Profiles to do that.

Each Role is associated with an Owner and a Default profile. Pay attention to these, because they really impact how a user works in the system. The profile is where you specify read-only, edit, delete and in some cases “no access” to record types. For each major type, you can further specify access to the related records, such as the Contacts associated with an Account.

Remember that there are two profiles for each Role. A Default and an Owner. Owner is stuff I own or my subordinate owns (if using MV). This should be the more “liberal” setting. Default is my level of access to everything else I can see, usually as a result of “Read All Records”.

And one more word on Profiles. You’ll notice that all profiles have the option “grantable to book members” and “grantable to teams”. The system has some default profiles used when adding users to teams and books and you can alter these or create entirely new ones.

Let’s Put It All Together

In our experience, most customers with “real world” data access and organizational needs end up using a mix of the tools we’ve talked about.

Starting with manager visibility, then enabling Book of Business for overlays and collaboration, sprinkle in some Teams for ad-hoc access.

These controls work very well together, although having a mix of controls in place may get confusing. That’s why it is important to document and understand them before implementing. And remember that at the end of the day the system is evaluating a user’s relationship to a record.

That’s an important point when it comes to troubleshooting. If a user isn’t seeing something they should, or is seeing something they shouldn’t, you need to consider that discrete record and the lens the user sees it through. It’s handy to remember that the most “liberal” controls win.

Share and Enjoy:
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitter
  • StumbleUpon
  • Technorati

Comments are closed.