Create a Revenue Reporting Data Dictionary Before Adding CRM Fields

In short: Before creating a CRM field, write down the decision or report it must support, the meaning of each value, its owner, and the source of truth. Check whether an existing property already serves the purpose. A small data dictionary helps teams avoid duplicate fields that use different names for the same concept.

A report says “qualified pipeline” while the CRM contains several fields called qualified, accepted, and sales-ready. The team may be looking at a real process difference—or at inconsistent labels that accumulated over time.

Adding another field can make the confusion harder to unwind. Start with shared definitions, then create a property only when the reporting or workflow need cannot be met with existing data.

1. Start with the decision, not the field

For each requested field, ask what decision it should support. “We need a marketing source field” is not enough. Does the team need to report original acquisition, the most recent campaign, a self-reported source, or a later influence? Each question may require a different record or history.

Write the business question and the expected grain: one value per person, account, opportunity, campaign interaction, or time period. If a person can have several answers over time, a single contact field may overwrite information the report needs.

2. Review the existing CRM before adding properties

Search for fields that already capture the concept, including synonyms, old labels, hidden fields, and values maintained by integrations. Check where each property is used: forms, imports, workflows, routing rules, reports, and data syncs.

If the existing field is close but incomplete, decide whether to improve its definition or preserve it for historical reporting. Do not create a second field simply because users cannot find the first one; improve the label, help text, grouping, or training if that solves the problem.

Property export and review tools can help identify existing definitions and redundant fields. HubSpot’s documentation, for example, describes exporting property definitions to review usage and identify outdated or redundant properties.

3. Document the definition and the allowed values

For each reporting-critical concept, record:

• Display name and system/API name: what users see and what integrations reference.
• Business definition: what a value means and what it does not mean.
• Record grain: contact, account, opportunity, interaction, or another entity.
• Owner and source of truth: who maintains the definition and which system supplies the value.
• Allowed values: the approved set, including “unknown,” “not applicable,” or “not collected” where appropriate.
• Entry point: when the value becomes knowable and who records it.
• History rule: whether later changes replace a prior value or add an event.
• Use and access: which reports, workflows, forms, and teams use the field.

Use a controlled list when consistent categories are necessary for routing or reporting. Use free text when the value cannot reasonably fit a maintained list and people need to record context. Do not force both into one field.

4. Define missing, changed, and conflicting data

A blank value should have a known meaning. It may mean not yet asked, unknown, not applicable, or data missing; those states lead to different actions. If the process depends on that distinction, represent it clearly rather than treating every blank as zero or “no.”

Decide what happens when two systems disagree. State which source wins for each field and who resolves exceptions. If campaign source changes after an opportunity is created, preserve the original source and record the later influence separately rather than silently replacing one with the other.

5. Approve changes through a small governance path

Before creating a field, ask the requester and system owner to approve the definition, allowed values, owner, and downstream use. Check whether adding the property changes a form, privacy notice, automation, integration, or report.

After a change, verify that the field appears in the right record view, accepts the intended values, and produces the expected report grouping. Keep a change log with the reason, date, owner, and affected processes. A field that no longer has an active use should be reviewed for archival rather than left as an unexplained option.

If recurring routing exceptions reveal missing or ambiguous data, use the separate routing-improvement cycle to confirm the cause before adding another property.

CRM data dictionary worksheet

• Business question or decision supported: ______
• Requested concept and record grain: ______
• Existing fields or reports reviewed: ______
• Display name, API name, and definition: ______
• Source of truth, owner, and entry point: ______
• Allowed values and meaning of blank: ______
• Change-history or overwrite rule: ______
• Forms, automations, integrations, and reports affected: ______
• Access, privacy, and retention considerations: ______
• Approval, verification step, and retirement trigger: ______

A useful data dictionary makes field meaning visible before the CRM grows another label. When the definition, owner, and source are clear, teams can build reporting around the business question instead of debating what a field was meant to mean.

If revenue reports use competing definitions or duplicate CRM fields, request a marketing diagnostic to map the metrics and field ownership.

Sources and scope

• HubSpot Knowledge Base: Create and edit properties — describes CRM properties as fields with configurable names, types, and rules; updated August 28, 2026.
• HubSpot Knowledge Base: Organize, delete, and export properties — describes grouping and exporting property definitions to review redundant or outdated properties; updated June 11, 2026.

This is a data-governance guide, not a vendor-specific schema design or privacy assessment. Confirm field behavior, retention, permissions, and integration effects in the organization’s actual CRM.