CRM: Avoid 3 User Identity Mistakes

CIO — Most of the advice in this column has been about customer data: leads, contacts, accounts, and transactions. Too often ignored is the CRM data that's about your users: employees who log in and manipulate data every day.

There are some user policies that are tempting, but have some nasty consequences. Here are three big ones we see all too often.

1. Naming Users By Their Function, Rather Than Their Name
The default login for CRM users is their name or email address. But it can be tempting to have the login be the person's function, rather than their real name.

If you have a large pool of workers that do essentially the same thing (e.g., "customer support operator 13"), this isn't the worst idea in the world. It does provide contextual information that isn't available from the user's own name, but it de-personalizes your users — never a good thing for system adoption or for HR. A better approach is to use the users Profile, Role, or other fields to provide that information in addition to the user's name.

The bigger issue, though, is that you're tempted to try...

2. Recycling License Identities
Due to the high turnover rates in low-level sales and marketing personnel, CRM systems are much more likely to have users come and go than any other part of enterprise software. In some groups, CRM users' life span averages little more than a year.

Of course when a user is gone, you want to deactivate their license as rapidly as possible so that the license can be used by the new user. But recycling the user license is not the same thing as recycling the license identity.

In most CRM systems, the license identity (which can be thought of as a user "slot" in the system) can never be deleted: the moment it is first instantiated, records and audit trails all over the system record pointers to the slot. Indeed, in Salesforce.com, even the user name (e.g., dtaber@saleslogistix.com) can be used only once across all customer instances...forever.

It's tempting to have an administrative policy that takes that eternal slot and recycles it for a new user when the old one is gone. This avoids the clutter of slots from users who will never be on the system again. Do not fall for this temptation.

Why? Because all the system's history and audit trails will still be pointing to that slot, so that history will be falsely attributed to that new user. Six months from now, nobody will remember exactly when the new user transitioned in. If the new user has a different function in the organization, nobody will remember what the previous user's exact role was. It's really hard to reassign accounts if you don't remember what the original user's territory was. Any historical reports will yield misleading results that cast doubt on the credibility of all the system's data. Not a good plan.

Further, recycling slots practically guarantees data quality problems over time, as people try to "fix" the data or reports to adjust for blurred user identities.

The best practice: never recycle user slots. Instead, deactivate old users and create new slots, explicitly transitioning the defunct user's data to the new owner(s) in a bulk data change.

What about the situation where a user leaves the company and comes back months or even years later? Usually, it's best to reactivate the user's old slot and transition the data that belongs to them in their new role. However, if their new role is completely different from what they were doing before (e.g., they used to be in the customer service call center, but now they're in marketing after business school) and their old identity could cause confusion in reports, using a new slot may be justified. In this case, their old avatar should be renamed (e.g., "joe.blow.OLD") to keep the identities clearly separated.

Continue Reading