One of the most exciting components of my career is when marketing automation projects become the catalyst for data normalization.

For many organizations, various applications, databases, and other software solutions operate within their own silos. There may be some 1:1 connections in place, data lakes, or all too often, manually updated CSV’s being emailed and shared all over the ether.

When we conduct a Salesforce Marketing Cloud implementation, a big part of discovery is helping to paint a picture depicting the art of the possible. Clients already have stars in their eyes from the demo phase with Salesforce as we begin the initial stages of system architecture.

Marketers are left keen on leveraging data from different sources to create the most personalized and relevant content possible for their subscribers. In order to accomplish this, data must be efficiently shared between systems and most importantly, related to the individual recipient. At this moment, many clients are setting out for the first time ever to create a one-to-many relationship across their sea of solutions.

This is where the catalyst leads to a reaction…

Salesforce and Salesforce Marketing Cloud have a nice relationship that leverages Contact IDs to keep data associated with the appropriate subscriber. But what happens when you want to introduce data from your accounting software or ERP? Many companies using that level of technology will have unique IDs that help manage cross-platform data, but many do not.

What happens when you’re looking for data from a 3rd party scheduling application that uses email address as the primary identifier/primary key? How and where do you map that data? Do you (can you?!) create a junction table to match email addresses to contact IDs? Or should they be matched to the unique IDs? What if a household department is sharing that email address?!

But data normalization isn’t just about primary keys. Let’s take a look at an oversimplified example:

Perhaps even in the face of years of technical debt and band-aid approaches somehow, IT has been keeping all things data together. We’re pumped about our new email tool and we want to email Bob Smith to thank him for attending a webinar.

• The accounting software has his first name as Robert.
• His account executive knows him as Rob and has kept his contact record updated in Salesforce as such.
• For whatever reason, he registered for the webinar as Bob.

How do we address him in this thank you email? How do we address him next week when we send him his monthly statement? If we automate an email from the desk of his account executive, how can we be sure he’s addressed as Rob?

This can all be manageable through appropriate system and data architecture, but it often results in a long overdue look at your current data models. Since each and every instance is unique, deep discovery is the most critical component to any successful Salesforce Marketing Cloud or Pardot implementation. If you ask your implementation partner to simply “turn the lights on” you may not like what you see.

While uniqueness comes with each and every implementation, there are a few baseline things that govern the approach to normalizing data.

Salesforce Contact ID

Propagating Salesforce contact IDs back to all of your platforms, databases, and applications is one of the best ways to keep your data aligned. While unique IDs generated by other systems may keep your data related, using Salesforce IDs keeps your data highly functional within your customer facing applications.

Data contained within your ERP or accounting software may be considered most “important” but the data in Salesforce drives all Sales and Marketing efforts. Third-party unique IDs can remain in play for other applications, but inclusion of Salesforce IDs will help support the best customer experience.

Contact Data Loading

For the functionality of most applications (and the sanity of your developers) housing as much data as possible on your contact records is one of the safest ways to enable data normalization. You will always need and require relational data for one-to-many relationships but keeping one-to-one data elements on the contact records helps keep things simple. This one-stop-shop approach to your more basic data will also simplify your marketing automation processes.

Identify Systems of Record and your Source of Truth

Each data element should have a formally identified system of record. This is the application that manages the most up-to-date values for a given record. Salesforce may be the SOR for contact data but it contains a billing address where the SOR is your accounting software. While Marketing Cloud is the SOR for email preferences, they may be shared down to Salesforce for visibility.

The Source of Truth is where a complete picture of your data should be made available. In a perfect world, this can be Salesforce with an appropriate level of security and sharing rules in place. In reality, we will often find it is a data lake holding information from each and every application in play. While we have a top choice for your Source of Truth, the most critical element is that one has been assigned.

While these governing ideals that can prepare you and your data for a successful marketing automation implementation, it is still of the utmost importance that you make time for deep discovery at the beginning of your project.