CRM Property Governance: How to Stop Fields From Multiplying

What is CRM property governance?

CRM property governance is the set of rules for how fields (called properties in HubSpot and Klaviyo, fields in most other CRMs) get created, named, typed, documented, owned and eventually removed. Its job is simple: every field in the system should have a clear purpose, one agreed meaning and someone responsible for it.

Without governance, fields multiply. Someone needs to track webinar attendance, so they create a field. A year later a colleague creates another for the same thing because they couldn’t find the first one. An integration adds 40 more. Eventually the system has four versions of “Lead Source”, the dashboard uses one of them (but which?), and every new workflow is built on a guess.

Governance doesn’t need to be heavy. In a typical company it’s a document, a naming convention, a short request process and a quarterly review. The rest of this guide covers each one.

Signs you need property governance

• Several fields with nearly identical names, like “Lead Source”, “Original Source”, “Lead source (new)” and “Source – Marketing”.
• Free-text fields used in filters and reports, full of spelling variants.
• Fields no current team member can explain, created by people who have left.
• Reps who don’t fill in fields because there are too many on the record.
• Reports that disagree because they read different fields for the same idea.
• Admins who are afraid to delete anything.

If more than one or two of these sound familiar, another cleanup won’t hold for long. The lasting fix is controlling how fields get created in the first place.

Start with a data dictionary

A data dictionary is a single list of every field that matters, with enough information that someone new could use it correctly. For each field, record:

• Name and internal name. The label users see and the API or internal name integrations use. They often differ.
• Object. Contact, company, deal, order, ticket, custom object.
• Field type. Text, number, date, dropdown, checkbox, calculated.
• Definition. One sentence on what it means. “The first channel through which this contact reached us” is a definition. “Source” is not.
• Allowed values. For dropdowns, the list and what each value means.
• Source of truth. Which system or process sets the value: a form, an integration, a workflow, a person.
• Who can edit. Whether users can overwrite it by hand, or only automation should.
• Used by. Workflows, lists, segments, reports and integrations that read it.
• Owner. The person who decides its allowed values and approves changes.
• Status. Active, deprecated, or scheduled for deletion.

You don’t need to document every field on day one. Start with the 30 to 50 that drive lifecycle, routing, segmentation and reporting. Our CRM data dictionary template has these columns set up.

Naming conventions that actually help

A naming convention should make it obvious, from the label alone, what a field is and who it belongs to. Something like this works for most teams:

Team or domain prefix, then a plain description, then a qualifier if needed.

• “MKT – Original lead source”
• “SALES – Disqualification reason”
• “CS – Onboarding completed date”
• “BILLING – Subscription plan (synced)”

A few rules worth adopting:

• Put dates in the name of date fields (“Last order date”, not “Last order”).
• Mark synced or calculated fields so people know not to edit them.
• Avoid version numbers and dates in names (“Lead score 2024”). If you need a new version, retire the old one.
• Keep the internal name readable and stable. Changing a label later is easy; changing an internal name that integrations depend on often isn’t possible.

Use property groups or folders, where your platform supports them, to keep related fields together.

Choosing the right field type

Field type decides whether a field can be used reliably later, and it’s hard to change once data exists.

Use dropdowns for anything you’ll filter, segment or report on. Free text is fine for notes and names. It’s a problem for industry, country, lead source or reason codes, because every spelling variant becomes a separate value.

Use single-select unless the thing is genuinely multiple. “Products of interest” can be multi-select. “Primary product” should not be.

Use real date fields for dates. A text field containing “March 2024” can’t drive a workflow delay or a date filter.

Use checkboxes carefully. A yes/no checkbox can’t tell “no” from “we never asked”. If that difference matters, use a dropdown with Yes, No and Unknown.

Prefer calculated fields to workflows that copy values. If a field is derived from others, a calculation stays correct. A workflow that copies values can fall out of sync.

Decide which system owns each field

When data flows between systems, two of them often try to write the same field. The CRM says the customer’s plan is “Pro”, the billing system says “Business”, and an integration overwrites one with the other every sync.

For every field that’s synced, decide:

• which system is the source of truth
• whether the sync is one-way or two-way
• what happens when both sides change it
• whether users can edit it by hand in the CRM

As a starting point, billing and order data should usually come from the billing or ecommerce system, and the CRM should only read it. Sales qualification fields belong to the CRM. Marketing consent should come from wherever the subscriber actually opted in, and never be overwritten by a sync that doesn’t know about it.

A lightweight process for new fields

The aim is to stop duplicate and unclear fields without slowing people down. A short request, answered before anything is created, does most of the work:

1. What question will this field answer, and who needs the answer?
2. Does a field for this already exist? (Check the dictionary.)
3. What type, and what are the allowed values?
4. What sets the value: a form, automation, integration or a person?
5. What will use it: a report, workflow, segment or routing rule?
6. Who owns it?

If the requester can’t answer question 5, the field probably isn’t needed yet. That one question removes a surprising number of “nice to have” fields.

Limit who can create fields to a small group of admins. Two to four people is plenty in all but the largest organizations. Everyone else requests.

How to retire fields safely

Deleting a field that something still depends on breaks workflows, lists and integrations, sometimes silently. Retire fields in stages:

1. Check dependencies. Look at where the field is used in workflows, lists or segments, reports, forms and integrations. Most platforms show some of this; integrations and external tools often aren’t included, so check those by hand.
2. Mark it deprecated. Rename it with a prefix like “ZZ DEPRECATED -” and update the description with the date and replacement field, so no one starts using it again.
3. Export the data. Keep a copy of the values with record IDs.
4. Hide or remove it from forms and record views.
5. Wait. A few weeks to a quarter, depending on how widely it was used.
6. Delete or archive. Some platforms keep deleted fields restorable for a limited period; don’t rely on that as your backup.

Duplicate fields need one extra step: decide which one survives, copy values from the other where the survivor is blank, and repoint everything that used the loser before retiring it.

Governing a system that’s already messy

Few teams are starting fresh. If you already have hundreds of fields:

• Export the full field list with fill rates and creation dates.
• Mark the fields you know are critical and document those first.
• Group the rest into “clearly needed”, “clearly unused” (low fill rate, nothing references it) and “unclear”.
• Retire the clearly unused in batches, using the process above.
• Put the naming convention and request process in place now, so new fields arrive cleanly while you work through the backlog.

Don’t try to fix every legacy field before adopting the rules. Govern what’s new from today and clean up the old in steps. Our CRM data cleanup guide covers fixing the values inside those fields.

Review on a schedule

A quarterly review keeps governance alive. Look at fields created since the last review and check they’re in the dictionary, look for new near-duplicates, check fill rates on critical fields, and progress any deprecated fields to deletion. It usually takes an hour or two once the dictionary exists.

For HubSpot specifically, our guide to HubSpot property architecture covers groups, field types and object choices in more depth. If you’d like help putting this in place on an existing system, our CRM Optimization service includes ongoing governance and review, and CRM Requirements Documentation covers writing the dictionary and rules up front.