GoHighLevel Tags vs Custom Fields: When to Use Which to Keep Your CRM Clean (2026)

If you've ever opened a GHL contact record and found 47 tags and a dozen custom fields with overlapping purposes, you already know the problem. Tags and custom fields are both essential tools in GoHighLevel, but they solve different problems — and confusing the two leads to a CRM that's impossible to maintain, workflows that fire incorrectly, and reporting that can't be trusted.

This guide gives you a clear framework for deciding which to use, how to name them, and how to prevent the sprawl that cripples most accounts within six months of going live.

What tags actually are in GoHighLevel

A tag is a label applied to a contact. It answers the question: what has this contact done, or what state are they currently in? Tags are binary — a contact either has a tag or they don't. They're designed to be transient and behavioural.

In GHL, tags are visible on the contact record, searchable in Smart Lists, and usable as triggers and conditions in Workflows. You can add or remove them via workflow actions, bulk contact actions, or manually. They don't carry a value — just presence or absence.

Good uses for tags: flagging that someone attended a webinar, marking a lead as an SMS opt-out, indicating that a contact came from a specific campaign, or showing that a trial has expired. These are states that may change, may be temporary, and don't need to store a specific value beyond "yes, this applies."

What custom fields actually are in GoHighLevel

A custom field stores a value against a contact, opportunity, or (depending on your plan and setup) other objects. It answers the question: what do we know about this contact that we need to read, display, or use in personalisation?

Custom fields hold persistent attributes — things that describe who someone is rather than what they've done. They support multiple field types: text, number, date, dropdown, checkbox, radio, file upload, and more. You reference them in email and SMS merge tags, in workflow If/Else branches, in opportunity records, and in reporting.

Good uses for custom fields: the contact's industry, their monthly revenue, the name of their business, their preferred contact time, their current software stack, their onboarding date, or their account manager's name. These are facts that don't change frequently and that you need to surface in communications or filter on in a meaningful way.

The decision framework: tag or custom field?

Before creating anything new, ask these four questions:

1. Does it have a value beyond yes/no? If yes, use a custom field. If it's just presence or absence, use a tag.
2. Is it permanent or persistent data about the contact? Custom field. Is it a current state or recent behaviour? Tag.
3. Do you need to use it in merge tags or personalisation? Custom field. Do you just need to segment or trigger on it? Tag.
4. Could this change frequently? Tags are easier to add/remove in bulk. Custom fields are better for data that's set once and referenced repeatedly.

Naming conventions that actually hold up

Naming is where most accounts go wrong. Without a system, you end up with tags like "webinar", "Webinar 2024", "attended webinar May", and "webinar attendee" — all meaning roughly the same thing, applied inconsistently across contacts and sub-accounts.

For tags: use a prefix that indicates category, followed by a specific descriptor. Keep it lowercase with hyphens. Examples:

• event:workshop-may26
• lead:paid-meta
• status:trial-active
• compliance:sms-optout
• action:callback-requested

For custom fields: use plain, readable labels that make sense in the GHL field list and in merge tags. Group related fields with a consistent prefix in the field name so they sort together in the editor. Examples: "Business: Industry", "Business: Monthly Revenue", "Onboarding: Start Date", "Onboarding: Coach Name".

Document your taxonomy in a shared sheet and review it quarterly. Any new tag or field created without matching an existing naming convention should require approval before it's added to the account.

A starter taxonomy for Australian agencies

This isn't exhaustive, but it gives most GHL-based agencies a solid foundation without over-engineering things from day one.

Tag categories to define upfront:

• lead: source and campaign origin (e.g., lead:paid-google, lead:referral)
• event: any webinar, workshop, or in-person event attended
• status: current lifecycle state (e.g., status:trial-active, status:churned)
• compliance: opt-out flags, DNC flags
• action: transient request states (callback, quote requested)

Custom field groups to set up in the contact record:

• Business profile: Business Name, Industry, Team Size, Monthly Revenue, Website
• Onboarding: Onboarding Date, Assigned Coach, Current Plan
• Preferences: Preferred Contact Method, Best Contact Time
• Reporting: Lead Source (dropdown), First Touch Campaign

For anything related to scoring contacts on behaviour, see the GoHighLevel behaviour-based lead scoring framework — tags play a central role in that system and it pairs directly with this taxonomy.

Automation pitfalls: what breaks when you get this wrong

The most expensive mistakes happen inside Workflows. Here's what to watch for.

Using tags for data that should be in fields — and vice versa. If you're trying to personalise an email with someone's business name but stored it as a tag, you can't merge it. Tags don't have values. Equally, if you create a custom field called "Attended Webinar" and set it to "Yes", you've made something that's harder to bulk-remove later and can't be used as a workflow trigger as cleanly as a tag.

Workflow re-entry and tag state. By default, many workflows in GHL don't allow re-entry, or re-entry resets the contact's position. If your workflow adds a tag at completion and the contact re-enters, understand whether that tag gets added again (it won't create a duplicate — tags are idempotent) or whether it gets stripped if you've placed a "Remove Tag" action somewhere in the path. Map out the full journey before relying on tag state for downstream If/Else conditions.

If/Else conditions on custom fields. GHL's If/Else branch checks field values at the moment the contact reaches that step. If a field is empty — because it was never filled in, or was cleared upstream — the branch will fall to the "else" path silently. Always include an "else" branch that handles blank/missing values, and consider triggering an internal notification when a critical field is empty. This is a core part of building reliable automation — covered in detail in the GoHighLevel workflow error handling guide.

Pipeline and opportunity custom fields vs contact custom fields. GHL separates contact-level and opportunity-level fields. If you're storing deal-specific data (e.g., quoted value, proposal sent date) on the contact record instead of the opportunity, that data won't surface correctly in pipeline views or revenue forecasting. If you're building out pipelines, read the GoHighLevel pipeline setup guide for revenue forecasting before deciding where each field lives.

Tag sprawl from third-party integrations. Zapier, Make, and native integrations often add their own tags automatically. Audit these regularly. A contact record with 80+ tags is almost certainly carrying legacy tags from integrations that were disconnected months ago — and they can cause false positives in workflow conditions.

Common mistakes to avoid

• Creating a new tag every time you run a campaign. Instead, use one tag per campaign type (e.g., lead:paid-meta) and store the specific campaign name in a custom field. This prevents tag lists that grow unboundedly.
• Storing opt-in status only as a tag. GHL has native email and SMS consent fields. Use those for compliance, and supplement with a tag for quick workflow filtering if needed — but don't rely solely on a tag for consent records.
• Never archiving or deleting unused custom fields. Unused fields clutter the contact record and confuse anyone managing the account. Review your custom field list every quarter and remove or consolidate fields that aren't being used in active workflows or reports.
• Using free-text custom fields where a dropdown would work. Free-text fields produce inconsistent data. "Ecommerce", "e-commerce", "eComm" are three different values in a filter. Use dropdowns for any field where the answer set is finite.
• Not documenting who can create tags or fields. In agency sub-accounts especially, giving every team member the ability to create new tags and fields leads to duplicates within weeks. Set a policy and enforce it.

If you want your tags and custom fields cleaned up and standardised across sub-accounts, book a strategy call with the HL Growth Partner team.

Book Your Strategy Call →

Frequently asked questions

Can you use both a tag and a custom field for the same data point?

Yes, and sometimes it makes sense. For example, you might store "Lead Source" as a custom field (dropdown) for reporting and personalisation, and also apply a tag like lead:paid-meta for easy workflow triggering. The custom field carries the readable value; the tag enables fast conditional logic. Just document the relationship so your team doesn't end up maintaining two separate things that get out of sync.

Do tags survive workflow re-entry in GoHighLevel?

Tags persist on the contact record regardless of workflow activity — they're not scoped to a workflow run. If a tag was added in a previous workflow run, it stays until something explicitly removes it. This means if your workflow has a condition "contact does not have tag X" to prevent re-processing, and no earlier step removed that tag, the contact will be filtered out on re-entry. Always map tag add/remove actions deliberately when building re-entrant workflows.

What's the difference between custom fields and custom values in GHL?

Custom values (sometimes called "Custom Values" in the GHL settings menu) are account-level constants — things like your business phone number, website URL, or signature block. They're not contact-specific. Custom fields, by contrast, are contact- or opportunity-specific and hold unique data per record. Custom values are useful for things that appear across all your templates but shouldn't need to be updated per contact.

How many tags is too many on a single contact?

There's no hard GHL limit, but practically speaking, more than 20–30 active tags on a contact is a sign that your taxonomy needs reviewing. A contact with 50+ tags usually has a mix of legacy campaign tags, integration tags, and status tags that were never cleaned up. The problem isn't performance — it's maintainability. When a workflow developer has to scroll through 60 tags to find the one they need, things get missed. Keep active tags under 20 per contact wherever possible, and build a removal step into every workflow that adds a tag.

Can custom fields be used in GoHighLevel Smart Lists?

Yes. Custom fields are fully filterable in Smart Lists, which makes them powerful for segmentation. You can build a Smart List of all contacts where "Industry" equals "Healthcare" and "Monthly Revenue" is above a certain bracket — something you can't do with tags alone. For any segmentation that needs to combine multiple attributes, custom fields in Smart Lists give you far more precision than relying on tag combinations.