GoHighLevel Custom Fields vs Tags vs Smart Lists

The short answer

Use custom fields for durable facts with a defined value, tags for lightweight labels or temporary coordination, and smart lists for saved views derived from current data. Do not use dozens of mutually exclusive tags to imitate a field, and do not store operational truth only inside a list filter.

The governing principle

Store each fact once in the most structured form available. A field answers a question, a tag labels a record, and a smart list asks the database a reusable query.

Recommended architecture

Create fields only when the value has an owner, type, allowed values, and business use. Use tags sparingly for provenance, campaign membership, exceptions, or migration markers. Build smart lists from fields, opportunity state, activity, and tags.

Prerequisites

Do not configure the production change until these inputs are known and recorded.

• Define the question the data must answer.
• Identify whether the value is durable, mutually exclusive, repeatable, or calculated.
• List reporting, routing, personalization, and integration consumers.
• Choose an owner and deletion or retention rule.

Implementation procedure

Build in the smallest independently testable increments. Record the reason for each decision, not only the final setting.

• Create a data dictionary before adding new fields or tags.
• Convert mutually exclusive tag families into dropdown or radio fields.
• Normalize legacy values and map blanks explicitly.
• Rebuild saved smart lists from the authoritative model.
• Update workflows and integrations in a controlled sequence.

Acceptance tests

A published asset is not necessarily a working system. Test normal, exception, duplicate, delayed, and recovery paths with traceable records.

• The same real-world fact cannot hold contradictory values.
• Reports group records without tag-string cleanup.
• Integrations receive a predictable type and allowed value.
• Smart lists update automatically when source data changes.
• Automation handles blank, unknown, and retired values.

Rollback and recovery

Keep legacy tags during a defined compatibility window. Write the new field without deleting old labels, compare cohorts, then retire legacy automation only after reconciliation.

Operating the system

Review field usage, blank rates, unexpected values, and unused tags quarterly. Prevent ungoverned field creation and document every value that affects routing, compliance, or reporting.

Failure modes to prevent

Tag sprawl creates contradictory states, free-text fields destroy reporting, and smart lists become hidden business logic. Another frequent error is using a contact field for an opportunity-specific fact.