Choosing the right fields is one problem. I covered it in my article on CRM fields that predict revenue. Keeping those fields understandable two years and three admins later is a different problem. That is what a data dictionary does. Every CRM I audit that has 400 properties and five versions of "Lead Source" got there the same way: fields were created on request, named on the spot, and never written down. This is the template I use to stop that.
The data dictionary columns
Set this up as a spreadsheet, one row per field, one tab per object (Contacts, Companies, Deals, plus any custom objects). Columns: (1) Object. (2) Field label, what users see. (3) Internal name, the API name in Zoho or the internal property name in HubSpot. (4) Field type, e.g. single-line text, dropdown, date, number, currency, checkbox. (5) Allowed values, the full picklist, in order. (6) Definition, one sentence a new hire would understand. (7) Source of truth, typed by user, set by form, set by workflow, synced from another system. (8) Required at, which stage or layout makes it mandatory. (9) Business owner, the person who approves changes. (10) Edit permissions, which roles or profiles can change it. (11) Used in, reports, workflows, integrations and scoring that depend on it. (12) Status, Active, Deprecated or Under review. (13) Created date and Last reviewed date. The "Used in" column is the one that saves you, because it tells you what breaks before you rename or delete anything.
A worked example row
Here is how a single row reads in practice. Object: Deal. Label: Close Reason (Lost). Internal name: close_reason_lost. Type: Dropdown, single select. Allowed values: Price, Competitor, Budget timing, No internal champion, Feature gap, Not a fit, Other. Definition: the primary reason the buyer chose not to proceed, selected by the deal owner when the deal moves to Closed Lost. Source of truth: user-entered. Required at: transition to Closed Lost. Business owner: Head of Sales. Edit permissions: Sales reps, Sales managers, Admins. Used in: Lost deal analysis dashboard, re-engagement workflow for Budget timing, quarterly win/loss review. Status: Active. Reviewed: [date]. Writing it at this level of detail feels slow for the first twenty fields. It becomes fast once you have a pattern, and it is the only way the next admin understands why "Other" triggers a mandatory notes field.
Property naming conventions
The rules I apply when creating any new field. Labels are in plain English, Title Case, no abbreviations a new hire would not know. Internal names are lowercase with underscores, set deliberately at creation, because HubSpot and Zoho both generate internal names from the first label you type and these are hard or impossible to change later. Prefix by origin when it helps: integration-synced fields start with the system, e.g. stripe_mrr or gads_campaign_id, so nobody edits them by hand. Dates end in _date, e.g. mql_date, sql_date. Booleans read as questions, e.g. is_icp_fit. Never put a year, quarter or campaign name into a field name; that is a value, not a field. Never create a field whose label differs from an existing one by a word, e.g. "Lead Source" and "Original Lead Source", without writing down in the dictionary exactly how they differ. HubSpot already has default source properties, so check those first.
Field type rules that prevent bad data
Default to dropdowns for anything you will report on. Free text is for notes, not categories. Use number or currency types for amounts, never text, or you cannot sum them. Use date pickers, never text dates, especially with teams across India and the US where 04/05 means two different days. Use a lookup or association instead of typing a company name into a contact text field. Keep picklists short and mutually exclusive, and add an "Other" option only with a required follow-up field. Document the picklist order in the dictionary, because order affects how reps choose. When you change a picklist value, record the old value and the mapping to the new one in a change log tab so historical reports still make sense.
The governance routine
A dictionary is only useful if it stays current. Three rules. First, a request process: anyone can request a new field through a short form asking what decision it supports, who owns it and what report will use it. If nobody can name the report, the field is not created. Second, an approval owner: one admin or RevOps lead creates fields, and edit access to field settings is limited to admin profiles. Third, a quarterly review: sort the dictionary by Last reviewed date, check the fill rate of each field in the CRM, and mark low-use fields Deprecated before deleting them. In HubSpot you can archive properties and restore them for a period, and in Zoho you can hide fields from layouts before deleting. Check the "Used in" column before either step.
Building the first version from an existing CRM
You do not need to start from a blank sheet. HubSpot lets you export all properties for an object from the Properties settings page, which gives you labels, internal names, types and options in one file. Zoho CRM shows field names and API names under Setup, Developer Hub, APIs, API names, by module. Export those, paste them into the template, then spend your time on the columns that need human judgement: definition, owner, required at and used in. Expect to find duplicates, fields nobody can explain and picklists with inconsistent values. Do not fix them all on day one. Mark them Under review, agree owners, and work through them in the quarterly cycle. If the clean-up is large, that is a separate project; my CRM cleanup article covers that sequence.
FAQ
A reference document listing every CRM field with its label, internal name, type, allowed values, definition, source, owner, permissions, dependencies and review status, so anyone can understand what a field means and what depends on it.
Plain English Title Case labels, deliberate lowercase underscore internal names, system prefixes for synced fields, _date suffixes for dates, question-style booleans, and no years or campaign names inside field names.
One RevOps or CRM admin owns the document and field creation. Each field also has a business owner, usually a sales or marketing leader, who approves changes to its definition or picklist values.