CRM Records: Now Who's the Dummy?

By David Taber, CIO |  Enterprise Software, data management

By their very nature, CRM systems tend to have a higher proportion of manually-entered data than any other enterprise software. And much of the data that comes into the system from integrations and imports are dirty. So data hygiene is a tough job in almost any CRM system.

It's ironic, then, that CRM systems actually have legitimate reasons to use dummy values in records. If you'll allow me to use some Jeff Foxworthy shtick here, I'll walk through some examples:

If You're Trying to Work Around Private Contacts, You Might Need a Dummy

Some CRM systems have the notion of a private contact -- a contact that is not linked to an account -- that can be created through imports or user actions. While private contacts are stored in the system, only the person who created them can actually see or modify them. Because they're supposed to be private, they don't show up in most searches or reports -- making them more than a little annoying to fix.

If your organization needs private contacts, fine. But most don't, and a way to avoid their creation is to attach contacts to a dummy account if the account name is blank. This can be easily achieved with a database trigger, typically built inside the CRM system's database but in some cases supplemented by code in integration servers.

We typically recommend that the dummy values be visibly flagged so they can't be confused with real accounts, and they're easiest to deal with if they show up at the very bottom of alphabetized lists in your local language. In most cases, a dummy name like "{{{dummy}}}" satisfies these criteria. In most situations, you want to be able to easily separate different types of dummies so that their sources are more obvious, such as:

• {{{web_dummy}}}

• {{{ecommerce_dummy}}}

• {{{tradeshow_dummy}}}

If One Side of an Integration has Mandatory Fields and the Other Doesn't, You Might Need a Dummy

Some systems have required fields for address, phone, e-mail, or other customer profile information, while others don't. When integrating the two, you'll have to put something in the fields of the more restrictive system. In some cases (such as "preferred language") it's safe to insert a default value if the information isn't available from the "other side." But with numerical data, you want to put in some data that could not possibly be confused with a legitimate entry. Addresses are relatively easy because they allow punctuation marks (like "{") and you can use Dummy strategies discussed above. But phone numbers are a bit of a problem because (1) more and more "impossible" phone numbers are now legitimate, and (2) what would be "obviously bogus" in one country would not be recognizably silly in another. +1 800 555 1212 is about as good as it gets, at least for the U.S.

Originally published on CIO |  Click here to read the original story.
Join us:






Ask a Question