How should you name fields, objects, and records in a CRM?

Naming feels like the most trivial decision in CRM setup, which is exactly why it’s usually made carelessly — and exactly why it’s expensive to fix later. A field called Custom_Field_17 or a deal named “Follow up” tells a future user nothing, and by the time hundreds of records carry an inconsistent pattern, cleaning it up is a project rather than a five-minute decision.

How should custom fields be named?

• Name for meaning, not mechanism. Renewal Risk Score beats Score_v2 — a field name should describe what it represents to someone who never saw it get built.
• Use one consistent case style across the CRM (e.g., Title Case for labels) rather than mixing conventions field by field, which makes reports and list views look inconsistent even when the underlying data is fine.
• Prefix or tag custom fields distinctly from system defaults where the platform allows it, so admins can tell at a glance which fields are standard and which were added later — useful when auditing a CRM data dictionary.
• Avoid abbreviations that only make sense to the person who created them. MRR is standard enough to keep; CustSegB2 is not.

How should custom objects be named?

Name a custom object after the real-world thing it represents — Property, Shipment, Renewal — using the singular form consistently, since most CRMs auto-pluralize for list views and mixing singular and plural custom object names creates visible inconsistency across the interface. Avoid naming objects after the department that requested them (Ops_Tracker) — departments reorganize; the underlying business concept usually doesn’t.

How should records themselves be named?

Record naming matters most for objects people search by name constantly — deals, accounts, and projects.

The pattern matters less than the consistency: pick one per object type, document it, and enforce it through required-field validation rather than a written policy nobody checks.

What happens without a naming convention?

Inconsistent naming quietly breaks the things that make a CRM useful — search stops being reliable, list views become unreadable at scale, and reports built on record names (rather than structured fields) produce misleading groupings. It also compounds: a new hire copies whatever pattern they see in existing records, so an early inconsistency spreads rather than staying contained.

What should you do next?

Write the convention down in one short page — one line per object type — and add it to your CRM’s data dictionary or admin onboarding doc. Then run a search for the worst existing offenders (blank names, “test,” “asdf,” duplicate-looking entries) and clean the top 20 before enforcing the rule going forward.