And now for something completely different.
If you’ve got a data quality problem, chances are you’ve read an article or three about how to improve that quality. However, through the course of that research, you’ve probably found that many of the articles are very much alike.
Now that’s not necessarily a bad thing; articles can only be so long, and it’s important to capture the most pertinent points first. Data deduplication, validation rules, reports; these are all potent weapons in the ongoing battle for data quality. Unfortunately, this means that other important things often don’t get mentioned, but let us not leave these soldiers behind! They can be just as important, and in some cases, more so.
The thing is, we have so much to say on the subject, that it’s spilling out around the edges of a single blog post! So we’re going to split this up into 2 posts! Without any further ado, here are the first 3 items:
1. Keep Your Containers Clean
If you’re keeping your food in dirty Tupperware, it stands to reason that your food won’t be clean either, right? The same goes for your data. If you want your data to stay clean, you have to keep the containers you keep it in clean as well. No one wants to consume your dirty Tupperware data.
As your org gets older, your org gets clunkier. You’ll have to replace formulas with text fields. You’ll end up being forced to test new fields in production (when you really need live data to develop against) that don’t turn out to be useful. You’ll have fields or functionality that get retired, or were developed by “that admin who is no longer with your company” and just never got removed.
I know how it is; it’s easier to just ignore these things and focus on the very real requests from your executive team accumulating on your doorstep right now. After all, they’re not doing any harm, right? Well, that’s the problem. Any field that you don’t remove still appears on reports and views, and only serves to confuse your users as they work with these very crucial tools.
That’s the thing that’s very easy to forget sometimes: Data quality is not a problem that only admins have to deal with. Yes, we handle many of those report requests, but if the ability to create reports has not been explicitly taken away from other users, they will make reports without asking you, and they will use the data they’re not supposed to. Yes, you told them not to use “Stage” because they should be using “Status” instead. They’ll do it anyway. Do your organization a favor and help keep things clean; if you don’t have the time to remove a field outright, at least rename it something like “OLD DO NOT USE”.
Additional tip: Making sure you fill in the Help Text for every field that is not completely obvious through its name will help keep your users informed. Once a year, make a point to go through your fields and make sure the Help Text is up-to-date and correct.
2. Picklists Where Possible
While we’re on the subject of field structure, let’s talk about picklists a bit. They are possibly your best friend as an admin, because it’s data that comes with built-in structure and governance. You don’t have to worry about misspellings, abbreviations (or lack thereof *COUGH COUGH STATES*) or divergent data that is useless in reporting. This may seem somewhat simple, but there are some places where picklists can be used that may not be so obvious.
It may seem like a good idea to create a checkbox field for users to indicate whether something is true, such as whether the account is a Priority Account, or to indicate if a contact is a key stakeholder. But I say unto thee, nay nay! There’s are many major problems with it:
- You can’t require a checkbox field. Go on. Try it. I dare you.
- An empty checkbox doesn’t equal a “No”. All you know for certain is that nobody checked it, and that may not have been intentional. Instantly, your data quality has taken a nose dive straight down to Crazytown.
- It doesn’t scale. After you add a few checkboxes, your page layout starts to get long in the tooth, so replace them with a custom object, or, if you REALLY have to, a multi-picklist. (More on that in a moment.) It also makes your reports grow out horizontally, which can also get out of hand fast.
The general rule of thumb should be: Admins should use picklists, where possible. There are plenty of exceptions, of course. Checkboxes are better for automated data and checklists. Never ever EVER use multi-picklists, unless you absolutely have no choice. They don’t play nice with workflow, formulas, validation rules, visual workflow, or anything other type of interaction beyond the setting of values. They are also not very useful in reports, as you can’t set up summary groupings based on where a value is included. Trust me, it’s a nightmare to get them to do what you want, one in which the only way to win is to wake up and do something else.
Generally speaking, use your brain and bounce ideas off your fellow admins, but for the most part, picklists are the way to go.
3. Tear Down That Data Wall
What do you get when you attempt to work with the same data, but in multiple locations? You get pure, unadulterated chaos, as though thousands of theoretical butterflies were all beating their wings in a concerted effort to make hurricanes.
When you have data living in disparate locations, you have disparate data schemas, disparate philosophies, disparate departments, all trying to accomplish the same thing in disparate ways. You might as well be eating lunch by committee. (“I think he should eat that bite first.” “He doesn’t like celery.” “Says who? He loves celery!” It’s only a matter of time before it comes to blows.)
Keeping your data separate is, frankly, just as ridiculous. Integrations are a key part of maintaining a uniform set of data and methodologies. Not only does it ensure that the data is uniform across each location, but it forces each stakeholding group to sit down at the table and communicate, lest their needs and desires be completely overlooked.
Show of hands, how many of you have finished a project, only to find out that the one guy who never showed up to any of the discovery meetings has a requirement that will need a near-complete rewrite, and without the rewrite the whole thing is useless or even damaging? Wow, that’s more than I thought.
It’s not just integrations that often get ignored. Frankly, (and I’m speaking from experience), it can happen with data that exists in different places in the same Salesforce org, across multiple objects. Try to use formulas where possible and feasible, rather than copying the data from one object to another with automation.
After all, it’s all too easy for related objects to slip into a state that eludes workflow rules, breaking the sync. New record types or picklist values can be added that don’t get accounted for in workflow, and users make unpredicted changes to data. If you’re making these changes responsibly, you should be doing an analysis to see the impact of the change on those fields, but even if you are, things still do get overlooked sometimes. Yes, I’m ashamed to say that this has happened in my org.
That’s it for today! We’ll have more to say on the matter in our next blog post, same Buddy time, same Buddy channel!