The What, How and When of Pardot Sandboxes

Pardot Sandboxes have been widely requested by Pardot users around the world. (You can take a look at the idea here). They allow you to test in a safe, non-live environment before making changes for real. While Sandboxes have been available in Salesforce for a while, they have been long awaited in Pardot. But now they are here…

What is a Pardot Sandbox and how is it different from a Salesforce Sandbox?

In Salesforce, a Sandbox is a replication of your current Salesforce environment allowing you to build and test new changes, and then push them back into production. There are several types of Salesforce Sandboxes, however there is only one type for Pardot.

A Pardot Sandbox is a Pardot Business Unit that can be provisioned from a Salesforce Full Sandbox. Thus you get access to a fully functional Pardot org, in which to build out new automations and test with a Salesforce Sandbox, that’s an exact replica of your Salesforce org.

Additionally, you’ll need to remember that you can’t push changes from your Pardot Sandbox into Production. This means that all changes made in your Pardot Sandbox have to be manually recreated in your live Pardot instance.

Lastly, remember that Salesforce Engage and B2B Marketing Analytics are not currently supported in Sandboxes.

How will this be useful for a Pardot user?

The key thing that a Pardot Sandbox will help with is testing and minimising risk. It allows your Salesforce team to ensure that the Pardot changes won’t interfere with any complex automations currently running.

This will be vital in a number of cases. For example if you have:

• Ever made a change without testing properly (!!!!)
• Not had enough visibility on what automations are running in Salesforce, and equally how those automations may impact the changes you’re making.
• Been in charge of a large enterprise org with a lot of automation and custom code.

It also allows users to have the space to try new ideas and be more creative with solutions without needing to worry about damaging data.

When should you use a Pardot Sandbox?

The most important time to make use of a Pardot Sandbox is when you are testing anything related to the flow of data between Pardot and Salesforce. Using Sandboxes for data flow will help prevent incorrect or accidental record changes and data deletion.

Here are a few scenarios:

1. Field mapping and sync level behaviour

Focusing your Sandbox testing efforts on Lead and Contact fields will help you determine which field level sync behaviour to use. Your three options are:

• Salesforce’s value is used as the master
• Pardot’s value is used as the master
• Use the most recently updated record

You will need to determine which Salesforce field names map to Pardot prospect fields to ensure that any data passing back and forth is accurate. You will be able to see if any issues arise by checking your sync errors, and by observing the data which is left in fields once tested.

2. Testing prospect sync

The default sync behaviour between Salesforce and Pardot is determined by the connector user’s permissions and role. Any records that aren’t visible to the connector user don’t sync to Pardot. If you’re using v2 of the connector, you also have Marketing Data Sharing rules to consider.

Marketing Data Sharing rules allow you to refine your sync behaviour further based on field values. For example, using a region field value to determine which Business Unit a prospect should sit in. Getting this right can involve making data changes to leads and contacts, thus Sandbox testing is appropriate.

3. Testing User Sync

When enabling Salesforce User Sync with your Pardot instance, you will need to map Salesforce profiles to Pardot roles. These roles will determine what your users will be able to see when logged into Salesforce or viewing your Pardot data from the Lead or Contact record in Salesforce. Configuring this in the Sandbox and verifying that this works as expected will be really useful.

When should you test without a Pardot Sandbox?

There are going to be instances where testing in a Pardot Sandbox is not as useful. These are scenarios where the changes being made are low risk, or can be removed easily without causing any issues. For example:

• Email Templates and Drafts – Because these are not customer facing (until you hit send), and there is testing functionality readily available in your Pardot instance, it would be a waste of time to use a Sandbox. Additionally, changes you make to Email Templates and Drafts will not be reflected in your Salesforce org.
• Landing Pages, Forms and Form Handlers – Test these assets in tools such as incognito mode in your browser. You can also use your own test data, thus a Sandbox would not be beneficial here.
• Static and Dynamic lists – Static lists don’t require testing, as you’re manually adding and removing prospects. Dynamic lists have a built in preview button so you can check them before you run them.
• Folder structures – Only your team use this. Don’t make more work for yourself!
• Page Actions & Custom Redirects – These can both be tested and adjusted from within Production simply by testing using incognito mode and test data.
• Dynamic Content – Whether your dynamic content is in an email, on a landing page or on your website – testing will always be possible within your Pardot Production environment.

What to do with grey areas….

There are going to be times where you could test in both a Pardot Sandbox and in Production. In these scenarios you’ll have to consider what is best for your organisation. Keep in mind that some of these items require a lot of time and effort to build in a Sandbox, and then manually rebuild. Consider that rebuilding a second time in a new system can lead to mistakes and human error.

• Scoring – If you’re just changing your scoring model, these changes work retroactively. This means you are fairly safe testing in Production. However, if you’re making changes directly to the prospects score (e.g. via completion actions) then you may want to test this in a Sandbox environment as these are not retroactive.
• Grading – Changing a Grading Profile shouldn’t be too problematic, however a lot of grading is run using Automation Rules which may require Sandbox testing.
• Automation Rules – Yes, there is a preview button built into Automation Rules, but they are incredibly powerful. With only one rule you can make giant irreversible changes to your data, without being able to undo them.
• Engagement Studio – Testing process for Engagement Studio programs will vary based on program complexities. This is down to the power and variety of options available within Engagement Studio. As a general rule, I would build these out in Production and test using test prospects. Still, you will need to assess the program, based on how many data changes are occurring.
• Third party integrations – If the integration impacts data (e.g. webinar connectors), use a Sandbox. However, for connectors such as Google Analytics / Ads, you could build this straight into Production.

If you are using Pardot Sandboxes for the first time, or have any questions, you can get in touch with us here.