Data Dictionary Template for Salesforce
A practical data dictionary layout for CRM objects, data extensions and Data Cloud mappings, with example rows and a simple process for keeping it accurate.
A data dictionary answers a simple question that is surprisingly hard in most Salesforce estates: what does this field mean, where does it come from, and who is allowed to change it? Without one, teams create near-duplicate fields, segments use the wrong date, and nobody can say which systems hold personal data.
This template works across Salesforce CRM objects, Marketing Cloud Engagement data extensions and Data Cloud data model objects. Keep it in a shared spreadsheet or your documentation tool, one row per field.
Core columns: identity and meaning
| Column | What to record | Example |
|---|---|---|
| System | Platform or org the field lives in | Sales Cloud production |
| Object or data extension | API name of the container | Contact |
| Field API name | Exact technical name | Marketing_Consent_Date__c |
| Label | Name shown to users | Marketing consent date |
| Business definition | One plain sentence a new starter would understand | Date the contact last gave email marketing consent |
| Data type and length | Platform type | Date/Time |
| Required | Whether the platform or process requires it | No; required by web-to-lead process |
Core columns: lineage and governance
| Column | What to record | Example |
|---|---|---|
| Source | Where the value originates | Web form via integration user |
| System of record | Which system wins when values disagree | Sales Cloud |
| Owner | Person or team accountable for the definition | Marketing operations |
| Classification | Personal, sensitive, confidential or public | Personal |
| Retention | How long it is kept and why | While consent valid; see retention policy |
| Used by | Reports, flows, journeys, integrations, segments | Consent sync to Marketing Cloud; Welcome journey |
| Last reviewed | Date and reviewer | 2026-09-30, data steward |
Example rows across platforms
The same customer attribute often exists in several systems. The dictionary should show each copy and how they relate. A short example for an email consent attribute:
- Sales Cloud:
Contact.Marketing_Consent_Date__c, system of record, written by the web form integration. - Marketing Cloud Engagement:
Customers_DE.ConsentDate, populated by a nightly sync, read only for marketers. - Data Cloud: mapped to a field on a consent-related data model object, used in segment filters.
Record the direction of flow and frequency for each copy. When someone asks why a contact was emailed after unsubscribing, this is the page that tells you where to look.
Classification levels
Keep classification simple enough that people actually apply it. Four levels work for most teams:
- Public: safe to publish, such as product categories.
- Internal: business data with no personal element, such as campaign codes.
- Personal: identifies or relates to a person, such as names, emails and order history.
- Sensitive: personal data needing extra protection, such as health, financial or government identifiers. Flag these for review before they are synced to marketing systems.
Keeping the dictionary current
- 01
Seed it from metadata
Export field lists from Salesforce object metadata and data extension definitions so technical columns start accurate.
- 02
Fill in meaning with owners
Run short sessions with each business owner to write definitions and confirm the system of record.
- 03
Make it part of change control
No new field, data extension column or Data Cloud mapping is deployed without a dictionary row.
- 04
Review on a schedule
Owners review their rows at a set interval and after major releases. Unused fields become candidates for removal.
- 05
Link it from where people work
Reference dictionary entries in field help text and in data extension descriptions.
Questions we hear
Should we use a spreadsheet or a tool?
How is this different from a data model diagram?
Do we include standard fields?
Who owns the dictionary?
Related reading
Data spread across too many systems?
We can help you build a data dictionary and model that your CRM, marketing and data teams all agree on.
