Overview

There are several considerations to consider when considering a Salesforce sandbox or Pardot sandbox.

😝 Ok, that was intentionally redundant and silly to get your attention and consideration! 😄 It also sounds like word salad coming from a central politician known for such things, (I’ll refrain from mentioning names). Now, onto our more serious topic…

Which test environment should you use: Pardot Sandbox, Pardot Demo Org, Pardot Dev Org?

Is setting up a Salesforce sandbox and/or a Pardot sandbox the best option for you?

In this article we outline some things to take into account before setting up a Pardot sandbox, and highlight some of the main differences between testing environments so that you can make the best decision on which type of testing environment or ‘playground’ will work best for your needs.

Hint: Use Salesforce Developer for no data, Salesforce Demo for pre-existing dummy data, Salesforce Sandbox for actual customer data.

We’ll focus more on the Pardot sandbox aspect (since after all we are Pardot experts strongly focused on Pardot), but nearly all of the same rules apply for a Salesforce sandbox and other test environments mentioned.

Keep in mind: All non-production environments – Sandbox, Training Environments, and Partner Dev orgs have email send disabled.

What is a Pardot Sandbox?

• Sandboxes for Pardot are test versions of a Pardot Business Unit provisioned within a Salesforce sandbox.
  • By its very nature a Salesforce sandbox will contain a copy of your actual Salesforce configuration and your Salesforce data (full or partial, although you’ll see below that Pardot requires full), which makes it a great option for testing in a non-destructive way since it is based on a copy and not the original, which remains untouched.

What is the main purpose of a Pardot Sandbox?

• The main purpose of a Pardot Sandbox is for testing anything potentially destructive; things related to the flow of data between Pardot and Salesforce, i.e. anything that could change records or cause data loss.
• Since your Salesforce sandbox will contain a copy of your actual Salesforce configuration and your Salesforce data, your Pardot sandbox will also contain some of your actual Salesforce data (based on whatever sync rules and object record type permissions you set up), so using a Pardot sandbox allows you to play around with your actual data without actually changing it, and thus can also help to ensure that any Pardot changes won’t interfere with any complex automations currently running in Salesforce.

• A Pardot Sandbox requires that a FULL Salesforce sandbox must be provisioned in Salesforce (a partial Salesforce sandbox will NOT work).
  • Is the client or Salesforce team ready and willing to provision a full Salesforce sandbox?
  • Is the client or Salesforce team ready and willing to provision the Pardot Sandbox and set the proper permissions and configurations needed for the sandbox environment and users involved in testing?
    • If not, is the client or Salesforce team going to provide enough user permissions for a Salesforce Partner or consultant to set up the sandbox environment properly? How much back-and-forth will this require? Is the back-and-forth and Pardot Sandbox set up accounted for in allocated project time?
      • Also consider if you’ll need to set up the Lightning Experience Email Builder which may require setting up a domain to host images and other configurations and permissions needed to support the Salesforce CMS.
• Pardot Sandbox cannot send emails.

NOTE: If the above requirements are not possible then perhaps a Salesforce Partner can provide a Pardot Demo site that can be used (see below for more about provisioning a Demo site).

• Refreshing a Salesforce sandbox deletes the associated Sandbox for Account Engagement (the Pardot sandbox will be de-provisioned; effectively deleted).
  • Make sure that the Salesforce team is well aware that refreshing the Salesforce sandbox deletes the Pardot sandbox since this action cannot be reversed. You don’t want the Salesforce team refreshing the Salesforce sandbox while you are working on and testing in your Pardot sandbox, since everything, the entire Pardot sandbox itself, will be deleted!
  • By its nature a Pardot sandbox is a very temporary thing. Any work done in the Pardot sandbox will inevitably and soon be destroyed/deleted.

• Anything created in sandbox can’t be pushed to production, so anything created in the Pardot sandbox that has value would need to be recreated from scratch in production.

• Sandboxes don’t support B2B Marketing Analytics, email sends, previews, or tests, Engagement History dashboards, the Google Ads connector, or Salesforce Engage.

• Data clean up may be necessary. If the Pardot sandbox added any new prospects or updated any data, then the Salesforce sandbox should not be pushed back to production without first deleting any new prospects or reversing any updated data.
  • Better yet, since this is not an easy to do and probably not worth the effort, to clean things up when are you done using your Pardot sandbox it is usually best to just refresh the Salesforce sandbox to push production data back to the Salesforce sandbox with clean data, noting that this action will delete the Pardot sandbox. This action will require close coordination between the parties testing in the Pardot sandbox and Salesforce team so you don’t refresh the Salesforce sandbox and wipe out the Pardot sandbox pre-maturely.

• An Account Engagement sandbox can’t be moved to a different Salesforce sandbox.
• Since a Pardot sandbox is a Business Unit, a Pardot sandbox cannot have additional Business Units of its own.

Required Editions

• Salesforce editions required: Unlimited or Performance edition (full Sandboxes are available at an additional cost with any Salesforce edition).

• Pardot editions required: Pardot Advanced (allocated up to two sandboxes) and Pardot Premium (allocated up to five sandboxes); and available as paid add-on for Pardot Plus edition.
  • Requires Pardot Connector V2.

Instructions on how to create a sandbox for Pardot/Account Engagement are located here (official Salesforce help file):

Create a Sandbox for Pardot/Account Engagement

https://help.salesforce.com/articleView?id=pardot_sf_connector_sandbox.htm&type=5

NOTE: If the above requirements are not possible then perhaps a Salesforce Partner can provide a Pardot Demo site that can be used (see below for more about provisioning a Demo site).

Testing in production could be a good option, depending on what you are doing.

Salesforce Admins might freak out, but there are several things you can do testing-wise in a Pardot production environment that are non-destructive.

If you stay away from the ‘gray areas’ you can easily stay under the radar and be safe if you exercise a little caution and judgement. Some elements are totally non-destructive, and some may have some effect on data if you do things wrong, so tread lightly.

Items that are considered safe and non-destructive for testing in production

• Email templates & drafts
• Forms
• Form handlers
• Static lists
• Dynamic lists
• Custom redirects (tracking links)
• Page actions*
• Dynamic content
• Email preference centers & unsubscribe page*
• Folders, tags, files
• Salesforce User Sync and Pardot roles

Gray areas that require discretion before testing in production*

• Engagement Studio Programs* (safe if not enable or if not affecting data that would sync to Salesforce)
• Scoring*
• Grading*
• Automation Rules* (safe if not enabled, but generally not recommended testing in production)
• Third party integrations*

Items marked with * probably require more caution and judgement before testing in production.

Dev Org and Demo Org provisioning for Salesforce Partners

If you are a Salesforce Partner you have a couple of other options besides a Salesforce Sandbox and/or a Pardot Sandbox. As a Salesforce Partner, you have access to free Dev Org and Demo Org instances.

Keep in mind that a Salesforce Dev Org or Demo Org is different than a sandbox, you won’t be able to use any of your orgs data, and you won’t be able to push any changes back to production. These are purely experimental zones for testing and training.

Choosing the right environment: Pardot DEV Org vs Pardot DEMO Org?

To this point we’ve explored some pros/cons about sandboxes, now let’s explore the main differences between a Pardot DEV Org and a Pardot DEMO Org.

Hint: Use Salesforce Developer Edition and Pardot DEV Org for no data, Salesforce Demo and Pardot DEMO Org for pre-existing dummy data, Salesforce Sandbox and Pardot sandbox for actual customer data.

Pardot DEV Org

• Has no Pardot data, Pardot is completely blank.
• Great for partners/developers who want to test with a clean org.
• Pardot Dev Org cannot send emails.

Pardot DEMO Org

• Includes fake demo data in Pardot and Salesforce.
• Great for sales/demos and training/onboarding. 
• Pardot Demo Org cannot send emails.
  • Salesforce help says “Allows for emailing using fake data and prospects (the data itself cannot be generated from Pardot).” and “Displays email send reporting metrics.” which I take to mean that you can’t send real emails, but you can view fake email statistics for demo purposes.

How to access and create a Salesforce Dev Org or Demo Org

Instructions on how to access and create a Salesforce Dev Org or Demo Org, which you can then create a sandbox for Pardot/Account Engagement, are located here (official Salesforce help files):

• Salesforce Dev Org Instructions
• Salesforce Demo Org Instructions

Summary

All of the mentioned test environments within this article have their place depending on the use case. Hopefully you found this article useful to the point where you may now have a better understanding of which test environment you should use for your purposes at hand.

If you need help setting up a Pardot demo for your team or for your client, or just need a little guidance, get in touch.