CRM Data Dictionary Template

A CRM data dictionary is a single reference that explains every field your CRM relies on: what it means, what values it can hold, which system is allowed to write to it, and what breaks if it changes. This template gives you the structure, a worked example for a few common fields, and a short governance checklist so the dictionary stays current after the first push.

Print or save as PDF

How to use this template

Don’t try to document every property on day one. Most CRMs have hundreds, and plenty are unused defaults. Start with the fields that something depends on: anything used in a workflow, flow, segment, list, report, routing rule or integration mapping. That’s usually 40 to 120 fields, and it’s the set where a wrong definition causes real damage.

Keep the dictionary in a shared spreadsheet or document, one row or block per field. Many teams also paste the one-line definition into the property’s description field inside the CRM, so people see it where they work. For the reasoning behind field ownership and naming, see the guide to CRM property governance.

Part 1: Dictionary header

• CRM and account: platform name and which portal, account or instance.
• Objects covered: contacts, companies, deals, tickets, orders, custom objects, profiles.
• Naming convention: the agreed pattern for new internal names (for example lowercase with underscores, object prefix, no dates or people’s names).
• Dictionary owner: who approves new fields and changes.
• Last full review: date.

Part 2: Field entry (copy once per field)

• Label: the name users see in the CRM.
• Internal name: the API or internal name. This is what integrations and workflows actually reference, and it usually can’t be changed after creation.
• Object: which object the field lives on.
• Group or folder: the property group it belongs to.
• Field type: single-line text, multi-line text, number, currency, date, date-time, single-select dropdown, multi-select, checkbox (boolean), calculated, rollup, owner/user, or another platform-specific type.
• Definition: one or two sentences, written so someone outside the team understands it. Include units for numbers and time zone for dates.
• Allowed values: for dropdowns, every option with its internal value. For numbers, the valid range. For text, the expected format.
• Default value: what new records get, if anything.
• Required: where it’s required (form, record creation, pipeline stage, none).
• Business owner: the team or role that decides what the field means and approves changes to its options.
• Source of truth: the one system whose value wins (CRM, billing, ecommerce platform, product database, enrichment tool, a person).
• Written by: every process that sets or changes the value: forms, imports, workflows, integrations, manual edits by which roles.
• Sync direction: for integrated fields, one-way into the CRM, one-way out, or two-way, and what happens on conflict.
• Used by: workflows, flows, lists or segments, reports, dashboards, routing rules, templates and personalization tokens that read this field.
• Sensitivity: whether the field holds personal or sensitive data and who should be able to see it.
• Fill rate: percentage of relevant records with a value, and the date you measured it.
• Status: active, deprecated (do not use; kept for history), or scheduled for deletion.
• Notes and history: changes to definition or options, with dates.

Part 3: Worked examples

Lifecycle stage (contact)

• Label: Lifecycle stage.
• Internal name: lifecyclestage.
• Object: Contact.
• Field type: Single-select dropdown.
• Definition: The contact’s current position in the customer lifecycle, as defined in the lifecycle map. Represents the furthest stage reached unless a documented backward move applies.
• Allowed values: Subscriber (subscriber), Lead (lead), Marketing Qualified Lead (marketingqualifiedlead), Sales Qualified Lead (salesqualifiedlead), Opportunity (opportunity), Customer (customer), Other (other).
• Default value: Lead for form submissions; Subscriber for newsletter-only forms.
• Required: On record creation.
• Business owner: Revenue operations.
• Source of truth: CRM.
• Written by: “Lifecycle: set MQL” workflow, “Lifecycle: set SQL from qualification outcome” workflow, deal-stage sync on closed won. Manual edits restricted to admins.
• Used by: Funnel dashboard, nurture enrollment, sales notification workflows, ad audience sync.
• Sensitivity: Not personal on its own.
• Status: Active.

Customer tier (company)

• Label: Customer tier.
• Internal name: customer_tier.
• Object: Company.
• Field type: Single-select dropdown.
• Definition: Service tier based on annual contract value at the last renewal.
• Allowed values: Tier 1 (tier_1, ACV of 50,000 or more), Tier 2 (tier_2, 10,000 to 49,999), Tier 3 (tier_3, under 10,000).
• Business owner: Customer success lead.
• Source of truth: Billing system.
• Written by: Nightly billing sync only. No manual edits.
• Sync direction: One-way, billing to CRM.
• Used by: Ticket routing, renewal reminder workflow, CS capacity report.
• Status: Active.

Lead source detail (contact)

• Label: Lead source detail.
• Internal name: lead_source_detail.
• Object: Contact.
• Field type: Single-line text.
• Definition: Free-text detail captured from the form’s hidden field (for example webinar name). Supplements, does not replace, the platform’s original source.
• Written by: Hidden form fields on landing pages.
• Used by: Event attendance report.
• Fill rate: 38%, measured last quarter.
• Status: Deprecated. Replaced by the “Campaign” dropdown; kept for historical reporting.
• Notes and history: Free text produced 200+ unique values. Moved to a dropdown with a fixed list.

The third example is the kind of entry that pays for the whole exercise. Without it, someone builds a new report on a field that stopped being maintained months ago.

Part 4: Dropdown option log

For high-traffic dropdowns (lead source, lifecycle stage, industry, product interest, lost reason), keep a separate log so option changes don’t break workflows quietly.

• Field: label and internal name.
• Option label and internal value: as stored.
• Meaning: when this option should be chosen.
• Added on and by: date and person.
• Retired on: date, and what existing records were remapped to.
• Workflows or reports referencing this option: names.

Part 5: Data dictionary checklist

Use this before you call the dictionary finished, and again at each quarterly review.

1. Every field used in an active workflow, flow, segment, report or integration has an entry.
2. Every entry has a business owner and a source of truth.
3. No field has two systems writing to it without a documented conflict rule.
4. Dropdown internal values in the dictionary match the CRM exactly (check spelling and case).
5. Fields with a fill rate under 30% are either fixed at the source or marked deprecated.
6. Deprecated fields are hidden from forms and record views but not deleted while reports still reference them.
7. Duplicate fields with the same meaning have one survivor named and a merge plan.
8. Personal and sensitive fields are marked, and access is restricted where the platform allows.
9. The definition text is copied into the CRM’s property description for the top 20 fields.
10. Anyone creating a new field knows to add a dictionary entry first.

When to bring the dictionary into other work

Before a migration, the dictionary becomes the mapping document. Before an automation build, it tells you whether the fields your trigger depends on are reliable. And during an audit, the “Written by” column is often where the real problem shows up: three processes writing to one field, each with a different idea of what it means. The CRM audit checklist points back here in its properties section for that reason.