Pardot orgs are notoriously hard to audit and document, with a less comprehensive setup and changes audit log than in Salesforce, and a lack of reporting capabilities for Admins. My hope is that as Pardot comes more closely integrated with Salesforce, the current Pardot Admin experience will become legacy, lost into the depths of the history books – and replaced with similar capabilities available in Salesforce.
Until then, documenting a Pardot org can be tedious and time-consuming. Often companies outsource this to Pardot consultants, who have the know-how on the gotchas you may not know about – it can mean ‘big money’ for consultants for something relatively non-technical! Let’s first define what a Data Dictionary is.
What is a Data Dictionary?
There can be multiple terms used to describe the way the contents of a database is documented, and arguably, they could be used interchangeably. The two terms that I have come across are:
- Data Dictionary: “the contents, format, and structure of a database and the relationship between its elements”. I think of it as a list of fields, their type, the fields they are mapped with, and any syncing behavior.
- Data Inventory: “what information you have, where it’s located and who has access to it”. A “list of datasets with metadata that describes their contents, source, licensing and other useful information”. I see the Data Inventory as a higher-level document, that looks at multiple systems rather than the nuts and bolts of one tool.
Data Dictionaries on Salesforce
In Salesforce speak, you can think of a Data Dictionary a copy of your Salesforce metadata. Meta-what?
Metadata is ‘data about data’ – contextual information about:
- The field’s purpose
- The reason for storing data in it
- Its type/category – especially if it contains PII (personally identifiable information)
- How long data can be stored in this field (data retention).
It may help to take a look at any field in Salesforce setup for comparison. Pardot is lacking a few field-level features that Salesforce has, including:
- Description Field (this is available on automation rules, but not on fields)
- Field Usage, eg. ‘Active’
- Data Sensitivity Level, eg. ‘Internal’
- A Data Owner (in Pardot, you could say the user ‘last modified’ becomes the Data Owner – but that’s not the best way to establish accountability, of course).
- Help text for users (or In-app Guidance)
- The ‘WhereUsed’ button, which answers the question ‘where is this field used’ in Salesforce‘, revealing any dependencies.
Flying Blind? Why You Need a Pardot Data Dictionary
Without proper documentation standards, you are ‘flying blind’ as Ian Gotts (Salesforce documentation guru) points out:
“Every change you make has a risk that it will break something in your Org. The impact analysis of every change with an undocumented Org is a huge time suck. Or you simply do no analysis and just hope (by the way, hope is not a strategy)”.
I consider documentation a skill, and so each individual will have their own flair on how to document their Pardot org. However, keeping a list of core items to check periodically will pay dividends in the long run.
Another reason is data compliance and safe handling. When GDPR came into effect in May 2018, many organisations confessed to not being as prepared as they had hoped. The regulation required a data management review across the business that sent people into a flurry. Although marketers were not the only ones that were affected, we found finding ourselves in the spotlight when it comes to data capture, privacy permissions and communication preferences.
A data dictionary ensures that every team internally across your organisation can read from the ’same page’, without requiring specialist knowledge to navigate specific tools, such as Pardot.
Generating a Data Dictionary of Your Pardot Data
Pardot objects (Prospects, Prospect Accounts, etc) are not the same as Salesforce objects, and as data can be created, updated and deleted in Pardot, this means your need a separate data dictionary for Marketing Automation.
Option 1: Excel
You can create a Data Dictionary manually in a spreadsheet, such as Excel/Google Sheets, which would detail the field, it’s type, which Salesforce field it is mapped to (on the Lead/Contact object), and the syncing behavior (which record is the master when a conflict in Pardot or Salesforce values occur).
Although practically cost-free and familiar for anyone to use, this is clearly not a solution for the long-term. Consider how often fields are added, removed or modified in Pardot, and how tedious this would make keeping a standalone data inventory up-to-date.
Option 2: AppExchange
To save this hassle, look to the Salesforce AppExchange for solutions.
One Data Inventory provider that I am familiar with is Elements Catalyst, having written an AppAssessor review on their tool.
The integration that Elements has with Salesforce processes a metadata sync nightly, meaning new and modified fields are ready for the Admin to categorize, using a dropdown menu (seen in the image below).
Above: an example of a Data Inventory, this one is developed by Elements.cloud.
While the image shows a Salesforce data inventory, there is also functionality to automatically generate a list of Pardot fields, ready for you to add the context. The Elements tool is very powerful (with impressive field analysis features worth checking out), and having Salesforce and Pardot Data Dictionaries recorded together will give visibility and invaluable control for organisations with frequently changing fields, and many free-wheeling Pardot users.
Summary
This post has covered Data Dictionaries, and how your Pardot org is in need of your attention to detail. Take the capabilities available in Salesforce for field categorisation and contextual information as a starting point for your Pardot Data Dictionary. Remember, each individual will have their own flair on how to document their Pardot org, but keeping a list of core items to check periodically will pay dividends in the long run.