Everything About Pardot Field Sync Behavior and Null Value Sync – in One Post

Share this article...

Data can flow into, and out from, your Marketing Automation tool from a multitude of sources. Although the reality for most marketers is an exhaustive list, what I can predict, is that marketers have two ‘hubs’ in common: Salesforce and Pardot. These are both powerful tools that each serve important purposes. however, when connected with one another, a battle commences – which is the source of truth? Which data should win when there’s different field data on each side? This is the challenge when using the Salesforce Connector for Pardot.

The good news is that you can define which side should become the master if there’s a difference in data. There are simple rules that are easy to follow, but exceptions arise when ’null’ values (blank fields) enter the mix. I will show you how both of these concepts work between Pardot and Salesforce, using 7(ish) scenarios – by the end, you will know everything there is to know about Pardot Field Sync Behavior and Null Value Sync.

Field Sync Behavior is Your Responsibility

As I mentioned, the good news is that you can define which side should become the master if there’s a difference in data. There’s always syncing considerations that you need to think through using your own use cases. I can show you how field sync behavior works, but it’s your responsibility to consider the consequences of applying these behaviors to each of your fields.

The whole point is to protect your data, and retain what makes sense – whether that’s the most up to date, the most accurate, or the best quality (think prospects entering dummy data into forms!). Knowing your sync through and through to protect your data becomes even more important when fields have null values, as you will see in the later use cases.

How does data sync between Pardot and Salesforce?

Have you ever seen this happen: you change a field value in Pardot, and minutes later, it’s changed back to what it was originally? Or, you delete data in Salesforce and it magically reappears soon after? It’s a frustrating loop that can send your users crazy.

In terms of field sync behavior, there are 3 options:

  • #1: Pardot is the master
  • #2: Salesforce is the master
  • #3: Most recently updated is the master
    (+ 3a: Caveats with using ‘Most recently updated’ as the master)

This is how it appears in the Pardot field settings (for each field):

#1: Pardot is the master

The value Pardot has for that field will always override Salesforce’s value.

When you would use this:

  • Capturing data from forms, where prospects are sharing updated information.
  • 
Importing updated information into Pardot
  • Pardot fields not mapped to Salesforce (obviously!)

 

#2: Salesforce is the master

The king of all CRMs, Salesforce is hailed as the ‘single source of truth’ for organisations across the globe. Protect the fort by not allowing bad data to override Salesforce data.

When you would use this:

  • Retain Salesforce data integrity,
    • avoid dummy data being passed into SF.
    • where Salesforce users (SDRs) are updating info.
  • Salesforce formula fields: these are determined by Salesforce using a specific set of conditions.

 

#3: Most recently updated is the master

This behavior takes the most recently updated record, whether that’s in Salesforce or Pardot. This setting was added a few years ago, and has proved very popular since, especially as you may not be able to define a consistent master each time.

When you would use this:

Where any of the following can be updating the data (any as the source of truth):

  • Prospects
  • Marketing data
  • Salesforce users
  • Salesforce automation

 

#3a: Caveats with using ‘Most recently updated’ as the master

Although “Most recently updated” is a very popular option for obvious reasons, it can often produce unexpected results with misguided use.

It boils down to the fact that the master is the most recently updated record, not most recently updated field. That means the master will switch when any change is made to the record, not just on your target field.

The Salesforce Connector sync can take up to 4 minutes to process, a lag which leaves a danger zone; if a change happens to that record in that time, the sync will not process as expected.

Here’s an example:

  • The Pardot field is updated, the sync to Salesforce begins.
  • Meanwhile, a Sales Rep. updates the record before sync completes.
  • As Salesforce is the ‘most recently updated’, Pardot will take Salesforce’s value – not the outcome we expected!

 

How does Pardot treat blank values?

Exceptions arise when ’null’ values (blank fields) enter the mix. When data is deleted from a field, the most important thing to note is that null value sync behaviour overrides the field sync behaviour; regardless of which is defined as the master for that field, null values are exceptions.

To distil it down further, Salesforce/Pardot has the mentality that any data is better than no data – the filled field will be chosen to enrich the blank field.

In terms of null value sync behaviour, there are 2 rules and 3 exceptions to cover:

  • #4: Pardot is null (blank)
  • #5: Salesforce is null (blank)
    (+ 5a: Salesforce is null with special connector setting)
  • #6: Null Exception – checkboxes
  • #7: Null Exception – protected fields (email)

#4: Pardot field is null (blank)

There’s a behaviour change pending very soon (at the time of writing this post). From Oct 14th 2019, if the Pardot field is blank, it will be overwritten by Salesforce’s value*.

Read this post on what to do ahead of the Winter ’20 Release changes (plus, it’s good background reading)!

*in case you’re interested, previously, if Pardot was the master for a field, and it was made blank, Pardot would be able to retain its blank value, and not get overwritten by Salesforce. This change simplifies the rules we have to learn!

#5: Salesforce field is null (blank)

Again, the golden rule is: a filled field value always trumps a 
blank, regardless of which is the master. This is shown in the diagram below:

#5a: Salesforce is null, with special connector setting

There’s an exceptional setting on the Salesforce-Pardot Connector called “overwrite null/blank values”. This setting is mysterious, as it’s not visible to users in Pardot, so sometimes, Admins may not even be aware it’s enabled. Moreover, to enable it, you have to make a request to Pardot support.

Of course, there’s valid business use cases for enabling this feature:

  • You want to enable your Salesforce users to clear field values, and stay blank.
  • You don’t want Pardot dummy data being constantly synced to Salesforce.

However, I urge you to think about this setting carefully, because it’s applied to all fields in your account, not just the one single field you want to target!

Walk through some of your own examples, here is one I recently thought through myself:

  • The ‘Type’ in Salesforce for a Lead is blank.
  • The Prospect submits a Pardot form
. The form has a Completion Action to update Type to ‘A’.
  • Pardot attempts to update the Salesforce Lead’s Type to ‘A’.
  • The Salesforce Lead’s blank (null) value wins over Pardot’s value.
  • The Prospect ‘Type’ value ‘A’ is cleared.
  • Salesforce Leads remain with blank Type.

Top tip: take a look into setting a default value for Salesforce picklist fields; this will alleviate many dropdowns from being unnecessarily blank!

#6: Null Exception – checkboxes

We will continue along the theme of exceptions, taking a look at checkbox fields.

From Salesforce’s point of view, checkboxes have two possible values: checked (true), or unchecked (false) – in other words, a Salesforce checkbox is never really considered blank.

Question is – how have you mapped your Salesforce checkbox fields with Pardot? The correct way is to map Salesforce checkboxes with Pardot radio button fields.

When a Salesforce checkbox field goes from checked to unchecked, Pardot will catch the ‘false’ value, being one of the options defined on the radio button. Sometimes, when checkbox fields are incorrectly mapped, the unchecking can revert itself, cause confusion!

#7: Null Exception – protected fields (email)

Email address is another exception you need to be aware of. To a CRM user, email address is just like any field – to a marketer, however, email is the golden key to a Prospect. Pardot also shares this opinion, as a Prospect record cannot exist without an email address.

If a Salesforce user deletes the email address value from the email field, then:

  • The Prospect’s email address remains unchanged
  • The Prospect becomes orphaned, and no longer syncs with the Lead or Contact in Salesforce. The Prospect will be marked [[crm_deleted]]* to show its tie with the CRM record has been severed.
    (*this will appear at the bottom of their Prospect record, and you can use this in automation rules too.)

 

NB: updating a Lead or Contact’s email address works differently – you can see the full run down here.

Summary: Next Steps

This post promised to show you all you need to know about Pardot Field Sync Behavior and Null Value Sync – using 7(ish) scenarios, you should be fully clued-up and confident to take responsibility for your syncing data across the connector. You can even make this part of a wider field audit/custom field clean up/Data Inventory project.

Do note that I may not have covered every single reason as to why you would choose the sync option – I have no doubt there are plenty of other use cases for each! If you’re ever in doubt, speak to a Pardot Specialist (which could save you data headaches down the line!).

2 thoughts on “Everything About Pardot Field Sync Behavior and Null Value Sync – in One Post

Leave a Reply