We at AppBuddy care about data quality, and so do you. As you work with Salesforce, one of the things you’ll notice is that your Salesforce data is affected by external data sources, automations that act on data, and data management processes. These sources provide a whole lot of data into your system, which for the most part is a good thing. The downside of inserting data from external sources and data automations is that some of the data is bad. Additionally, data management processes that are poorly designed means a higher likelihood that users don’t update data regularly and it is incomplete or becomes out of date.
As we pointed out in “Conquering Salesforce Data Quality Problems over the Data Lifecycle,” this data can include: wrong close dates, wrong Opportunity stages, wrong project statuses, and data that is missing from half the fields on your custom objects. Taking all these factors together, data can truly become a mess.
Let’s talk about how external data sources, automations, and manual data management processes can affect data quality in your Salesforce org so that you can identify data quality problems yourself.
Data Sources that Are External to Salesforce
Many times data is piped into Salesforce via an import or an integration. This affects your Salesforce org during the data creation and subsequent data update phases. A classic example of this is when data is imported into Salesforce from a marketing automation system. In this example, a person could fill out a web form on a company’s website, and the web form then saves the data into marketing automation system. These web forms are ubiquitous across the internet and are used to sign up for e-books, webinars, white papers, and for any number of other reasons.
If the person fills the form out with accurate data, then everything is fine. The problem starts when a person enters inaccurate data. To further complicate the problem, web form data is usually not scrubbed for accuracy by a company’s users or by Salesforce data validation rules at the time of insertion. (Many times, but not always, validation rules at the time of insertion aren’t put in place so the integration doesn’t fail, and post-insertion data quality measures are usually necessary.) Therefore bad data is stored in the marketing automation system, and guess what, it is also stored in a company’s Salesforce org. So along with good leads, a company has a lot of leads that have “asdf” as the name and “123” as the company.
Salesforce automations are custom code, workflows, or apps that update data over time. Automations affect data over its lifecycle -- as it is created, updated, and eventually, deleted. Sometimes apps that automatically create or augment data run as batch processes in the background, or are initiated by an admin or a user. Therefore, there can be an overlap with a company’s manual data management process (see a discussion of this below).
Take the example of a company that needs to generate quotes inside of Salesforce. A Salesforce user could create the Opportunity Line items they need, and then hit a “Generate Quote” button on the Opportunity. With the help of an app like Conga Composer, for example, the intended result would be the quote is produced.
Let’s consider what happens when a quote is given to a prospect mid-month and the quoted amount needs to be pro-rated. In such an example, a billing software system is employed that computes pro-rated charges by inserting the appropriate charge line item records. These charge line item records contain important information like the pro-rated amount a customer was to pay if they started a term mid-month. Seems straight forward enough, but it tragically fails if this Salesforce logic isn’t integrated with the company’s billing software. The billing software would generate invoices based on its calculation of the pro-rated amount. This may differ from a custom attempt to reverse engineer that calculation in the “Generate Quote” automation where the quote line items are created. The result is that Finance would send out invoices with one set of numbers that didn’t match the quote that Sales sent out! You can imagine what problems this could lead to in building customer relationships after a sale.
In our example above, it wouldn’t be very long before a data management process broke down as a result of an erroneous automation. Take away: check your data automations for errors, as well as the processes that initiate them.
Salesforce Data Management Processes
These are the manual data management processes that people conduct using a user interface, or UI. Salesforce record detail screens or GridBuddy grids are an example of such UI’s. People conducting data management processes interact with data in all phases of the data lifecycle -- not only creating, updating and deleting, but data management UIs are unique in that they allow users to read data too. The importance of this lies in the fact that visibility into the right data is crucial for users to make accurate manual editing decisions.
Data management is an area where users can wreak a lot of havoc on our Salesforce data, not only by making mistakes, but quite often by doing nothing and not keeping the data “alive”. The temptation of many teams who administer Salesforce is to limit what people can do. While restricted permissions and validation rules help prevent bad data, too much of a good thing, well, can lead to a bad thing. In the worst case scenario, processes are too restrictive and complicated, users don’t adopt the data management process, and data quality suffers severely as a result.
Getting data management processes right is an area that AppBuddy has dedicated its entire focus on. We have a few guiding principles designing the right data management processes all the time which I will cover in my next post.