Fighting the Halloween Monsters in Your CRM System

There are all kinds of monsters in your CRM system. Each kind requires a different strategy. All require modification of user practices – “Don’t go into the basement!” – and corrective action in your database.

Let’s start with the simplest ones, which are simple because they’re entirely under IT control in the first place.

Frankenstein: An Uncoordinated Monster Haphazardly Sewn Together

Dr. Frankenstein sewed a collection of bits together. His monster’s gait was clumsy and slow. Software that you deploy in an uncoordinated way is the root cause of Frankenstein monsters in the CRM system.

[ Also: How IT Can Scare Off BYOD Monsters in the Closet ]

A CRM system may have hundreds of workflows, validation rules, formula fields, buttons, style sheets and JavaScript fragments that all interact – and they all have to work right. It’s all too easy to make a “nothing” change in a field definition and forget to make the corresponding code updates in a dozen other places. It’s an instant bug-fest. (That’s another horror movie for another day.)

Here’s how to detect and kill Frankenstein in your CRM system:

• Install Eclipse on a PC or Mac, and add the Force.com plug-in.
• Use that IDE to pull in all the metadata in from your Salesforce.com organization.
• Use the IDE Search function for these keywords: Javascript, includescript and requirescript.
• Inventory where all these most troublesome elements are located. Figure out how they’re linked.
• Before making any future change, use the Search function to do an impact analysis.
• Get serious about in-place documentation.
• Watch Mel Brooks’ Young Frankenstein.

Space Monsters: You Know They Did Something, But You Can’t See Them

In monster lore, bug-eyed extraterrestrials aren’t much like Frankenstein. In CRM deployments, though, space monsters are also caused by software you installed, particularly in the form on system integrations.

You sign off on the integrator when things work during business hours. At night, UFOs occasionally buzz the system, leaving only failed transactions in their wake. Typically, there isn’t enough data to replicate or troubleshoot the problem, particularly when outside services such as payments or shipping gateways are involved.

Executives won’t accept the swamp gas explanations, so here’s how to detect and kill space monsters.

First, turn on the sensors:

• Do daily snapshots of all tables touched by external integrations.
• Add system asserts that cross-check that transactional result’s footprint in production code, not just test code.
• Hit the system’s “Run all tests” button on a weekly basis to check out new validation rules, constraints or other error-inducing elements that have been introduced to the system.

Next, leave the cameras running 24/7:

• Get serious about error logging and audit trails throughout your Web services. Yes, you’ll have to pay for the storage and tools. Get over it.
• Create code that writes transactional details to log files even when an error isn’t thrown. Keep those logs for at least a quarter – better yet, a year.

Finally, watch Tim Burton’s Mars Attacks.                         

Zombies: Inactive, But Still There

The undead want nothing more than to eat your brains. Fine. Be that way.

CRM zombies result from records owned by dead users. Because the users are inactive, the access control system typically makes the records they own invisible to all but the super user. Regular users wonder if their brains have been eaten because records they know are there just can’t be seen any more.

Here’s how to avoid and defeat CRM zombies.

First, change your administrative policies:

• Prevent users from deleting records.
• Don’t “recycle” user slots; instead, deactivate the user and transfer his or her license to the new user.
• Transfer all of the deactivated user’s records – except closed tasks, cases and opportunities – to live users, too.

Next, look in your system for zombie records using a query such as the following:

SELECT Name FROM Lead WHERE OwnerID NOT in

(SELECT id FROM user WHERE IsActive=True)

Finally, memorize this joke: What do vegetarian Zombies urgently want to eat? Grains. GRAINS!

Doppelgangers: Duplicates That Can’t Be Trusted

Here, the problem’s as clear as day: Duplicates. Sometimes, this problem stems from user laziness (that is, not searching before creating a new record) – but as often as not, there are system and process issue as well (that is, records are invisible or are being created by a flawed integration).

[ More: CRM’s Identity Crisis: Duplicate Contacts, Part 1 and Part 2 ]

Causes are many and varied, depending on the kind of record being duplicated. So are the solutions. Here’s how to detect and defeat doppelgangers:

• Don’t set your expectations too high, too fast. Fixing deep duplication problems can take several months.
• Expect to discover business-process problems, software issues, questionable data feeds and training/usability issues. Since these are all intertwined, work them in a step-wise fashion.
• Read this discussion of CRM data deduplication dilemmas.
• Watch Steve Martin in Dead Men Don’t Wear Plaid.

Poltergeists: Troublesome Spirits That Easily Manifest

Talk about close encounters of the undead kind. While similar to doppelgangers, poltergeists are organizational entities (companies) rather than people (leads/contacts). Thanks to mergers, acquisitions and divestitures, as well as other facets of corporate finance, a Fortune 100 enterprise may be represented as dozens or even hundreds of accounts in the CRM. This is an even more severe issue with the business units of Japanese keiretsu. If your CRM is integrated with the accounting and distribution systems, every new ShipTo and BillTo address may spawn a new account. You can get quite the army of poltergeists.

The root cause is a flawed or out-of-date account hierarchy. For most American companies, there are solid solutions. Things get sketchy in Europe and quite murky in EMEA but, generally, here’s how to overcome poltergeists:

• Create policies and practices around using “official sources” for company names and parent-child relationships.
  • Populate account records from these official sources.
  • Create a new field on the account record to store the “friendly” or “street” name” for a company. That way, the system-standard field can be used for the formal corporate entity that nobody will spell correctly.
  • Remove the create privilege for accounts for most users.
  • Train users on how to live in the new world.
• Use DUNS, Experian, AM Best, or other corporate entity ID standards as the foreign key for account records. Create records for the entire corporate hierarchy using “parent” and “ultimate parent” pointers in those databases. (If you’re outside the U.S., do your homework to find the best source for corresponding IDs.)
• Rework your integrations so they don’t create spurious account records.
• Clean up your database, flagging questionable records users until they fit the new model. Don’t hide them entirely, as that’s an invitation to dupe creation by users.
• Memorize this joke: Why did the dead chicken cross the road? Because it was a poultry-geist.

These monsters aren’t just moviegoers’ fantasy. They’re all too real, with practical consequences for your users and reports alike. Defeating them may not be fun, and there may be casualties, but they’re part of the software debt that needs to be managed along with the rest of your agile project inventory.