CIO — 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

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.

If You Need to Stop Absurd Mail Merges, You Might Need a Dummy

Many CRM systems get data from Web forms, some of which aren't under your company's control. Consequently, a good percentage of your lead and even contact records will have ridiculous values for name or address fields. Just because some of the values are junk doesn't mean you want to throw the whole record away — it may still be a valid e-mail that you want on your subscriber list. Let's say one of those good e-mail addresses claims to be for someone named "asdf asdf"...you don't want to have a mail merge that starts off with "Dear Mr. Asdf..."

You can detect these silly values with a junk dictionary or a data cleansing service, but you don't want to replace them with blanks even if the system would let you. Instead, use dummies like {{{empty}}} or {{{junk value}}}, and add logic to your mail merge routines so that the dummies cause the "Dear..." line to be "Dear valued customer" or just dropped entirely.

If You're Trying to Avoid Using Person Accounts, You Might Need a Dummy

Some CRM systems have created Person Accounts as a way to represent consumer and other special contacts that will never be associated with a company. Person Accounts are helpful because they avoid the creation of bogus Account records with a singleton Contact (such as "John Doe" of "John Doe" company). However, Person Accounts have some nasty side effects, particularly when writing reports.

A simple alternative is to create a few dummy Accounts, such as:

• {{{individual}}}

Continue Reading