I had the craziest dream this past weekend… I was part of a group of SFDC admins who were locked in an asylum for no discernible reason. We had to locate and deactivate a series of records in a database in order to get out of the asylum. But we couldn’t find them because they all had bizarre, illogical names!

It sounds silly, but it was a really disturbing dream – most likely brought on by combining the pressures of my new job with a marathon of American Horror Story: Asylum episodes. My reaction to the nightmare was (naturally) to dissect it. What if those records had been easier to find? Could we all have won our freedom if there was a simple naming convention in place?

As far back as 2005 (I know, right? Did we even have internet back then?) Toshiba America Medical Systems, a.k.a. TAMS, put naming conventions in place from day one as they implemented their CRM system. An employee was quoted as saying “It’s very clear what each report is. We use descriptions by month, quarter, half. We don’t use technical names.” This practice extended to files and documents as well, to make sure that everything had the same look and feel.

In the years since then, many articles have been written on data integrity, all with similar points, but one that really stands out is standardized naming conventions. It seems like such a little thing, but think about it – how many duplicates have you seen that have massive, obvious differences? None! Duplicate records in your database will most likely have some tiny, almost uncatchable detail that makes them ever so slightly different. Do you leave the “Inc” and “LLC” at the end of the account name? Do you allow punctuation? “Google.com” and “Google Inc” and “Google, Inc.” could end up as three duplicate accounts if you don’t have some kind of a rule for that. And don’t even get me started on international phone numbers…

Another great way to avoid slight variances in duplicate data is to use picklists instead of text fields. Nothing is more annoying than trying to run a report summarized by country and getting separate totals for England, UK, United Kingdom, The United Kingdom, Great Britain, etc. If you create a picklist with country names formatted to your liking, you can avoid simple human error altogether. Personally, I am a big fan of the globally accepted two-character country abbreviations.

Still not convinced? I have seen dozens of job postings lately that place heavy emphasis on data naming and standardization. One of the Professional Qualifications I saw listed? “Proven ability to create naming conventions, formats, and standards for data.”

Don’t know how to fix your naming issues? Well, I can’t write your naming convention for you – they are all different. But here are the three steps to solving the problem:

• Decide on naming conventions for the objects and/or fields in your database which are causing your data issues, using logic and feedback from each department of your organization.
• Put validation rules, picklists, and workflow rules in place to automate and avoid errors.
• Go back and clean up the existing data! This is the last step because it will take the longest – that’s why it is best done after your new procedure is in place. (Be careful if you are changing the field type!)

Trust me – strong naming conventions just might keep you (and your users!) from going crazy.