We at AppBuddy don’t like bad data one bit, and neither do you. If you’ve been working with Salesforce for any length of time, you probably have bad data. Wrong close dates. Wrong Opportunity stages. Wrong project statuses. Data missing from half the fields on your custom object. It’s a mess. We understand.
When a professional services team uses bad data, deliverables are missed. When bad data corrupts your Salesforce customer service solution, customers aren’t contacted in a timely manner, and they don’t renew due to bad customer service. And when bad data informs a sales forecast, it is often missed, causing a negative chain reaction company-wide, especially for publicly traded companies.
So, how does bad data get into your Salesforce org to begin with? This is easy to understand if we consider what is affecting data over the course of its lifecycle.
What Affects Your Salesforce Data Quality?
There’s good news. There’s a finite amount of things that can affect your Salesforce data throughout its life. These are external data sources, automations that act on data, and data management processes. If you have a data quality problem, you need to look at how any of these three things are affecting data throughout its lifecycle in your Salesforce org.
Understanding The Data Lifecycle
The data lifecycle is your best friend when you analyze data quality problems. Looking at what happens to data throughout its existence is exactly how a programmer would go about analyzing the same problem. It’s a simple and structured way to sort through the mess.
The lifecyle of data can be thought of just like the life of a butterfly. It begins with creation, changes throughout the time it exists, and ends at the end of life. In technical terms, we call these changes that affect the state of data in it’s life cycle “CRUD”, which even though it sounds dirty, it’s not. It simply stands for ‘create’, ‘read’, ‘update’, ‘delete’. Let’s look at each briefly.
Creating Salesforce Data
Records are created in Salesforce all the time. This can be done via external data sources (e.g., integrations where the external system inserts data into the database in question or imports of lists where the import does the same thing), automations (e.g., a workflow that creates a task in Salesforce) or a data management process (e.g., a user manually creates a record in Salesforce). Technically, all these methods have one thing in common -- in the background, they run an “insert” command on the Salesforce database.
Reading Salesforce Data
Any time people need to see a record whether it’s pulling up a record detail page or looking at a record in a report, they are reading data. In technical terms, it is when a “select” command is run against the Salesforce database. Reading data doesn’t directly affect data quality since nothing is happening to the record while it’s read, but it is often crucial in helping users make decisions when they are editing or deleting Salesforce data.
Updating Salesforce Data
Edit and update are synonymous terms. Any time someone says they are editing a record in Salesforce, in the background, that operation runs an “update” statement against the Salesforce database. Updating or editing Salesforce data can happen in any of the scenarios outlined in the “Creating Salesforce Data” section above. For example, in a data management process, a user can update a record soon after she created it.
Deleting Salesforce Data
When you blow away a record in Salesforce, technically what is happening in the background is a “delete” command is run for that record against the Salesforce database, and it goes bye bye.
Integrations and automations (e.g., a trigger in Salesforce that deletes a record) can delete Salesforce data, though these scenarios are typically less frequent that when they create or update data. Deleting data is more likely to happen in a manual data management process in Salesforce, though there are typically restrictions in place to prevent users from delete data liberally. (I’m sure someone will have an exceptions to these scenarios, so please feel free to comment on Twitter - @appbuddy - or in the comments section of this post.)
So What’s This All Got to Do with Data Quality?
What you know now is a framework to think about what affects data throughout its lifecycle. In other words, data gets created somehow, can go through many edits throughout its lifetime, and then it gets deleted. If you have a data quality problem, you just need to look for problems where data is getting created, updated or deleted in a way it’s not supposed to. Structuring your analysis of data quality along these dimensions will help make tackling your data quality problems seem less scary and overwhelming.
As mentioned earlier, external data sources, automations that act on data, and data management processes are the things that can act on your data through its lifecycle. See my next post, "How Data Sources Affect Salesforce Data Quality", for a deeper discussion about how to they can cause data quality problems in your Salesforce org.