GoHighLevel Custom Values and Custom Fields: The Difference That Saves You Hours

Almost every messy GoHighLevel account has the same root cause. Someone hard-coded a business name, a phone number or a booking link into forty emails, twelve SMS templates and six funnels. Then the client rebranded, changed their number, or moved to a new calendar — and now somebody is opening forty emails one at a time.

Custom values and custom fields exist to prevent exactly that. They look similar, they are used in the same merge-tag syntax, and they do completely different jobs. Getting the distinction right is the difference between a snapshot you can deploy in an hour and one that takes a day of find-and-replace.

The Core Distinction

A custom field stores information about a contact. It varies from person to person. Their policy renewal date, their property address, their preferred technician, the size of their roof. One field, thousands of different values — one per contact.

A custom value stores information about the business. It is the same for everyone in the sub-account. The company name, the office phone, the booking link, the support email, the address in the email footer. One value, used everywhere.

The test is simple: would this be different for two different contacts? If yes, it is a custom field. If no, it is a custom value.

Custom Values: Build Your Snapshot Around Them

Custom values live at Settings → Custom Values. Each has a name and a value, and you reference it with a merge tag wherever text is written.

Their real power shows in snapshots. If your templates reference {{custom_values.business_name}} rather than “Apex Plumbing”, deploying that snapshot to a new client means filling in a list of values once — not editing every asset.

The Custom Values Every Snapshot Should Have

• business_name — used in every email, SMS and page.
• business_phone and business_email
• business_address — required in email footers for compliance.
• booking_link — the calendar URL, referenced everywhere you ask someone to book.
• website_url
• review_link — the Google review URL for reputation requests.
• owner_first_name — so emails can be signed by a person.
• support_hours — used in after-hours messaging.
• unsubscribe_text or similar compliance boilerplate.
• primary_offer — the headline service, if your templates reference it.

Ten values, filled in once per client, and a snapshot that previously needed two hours of editing now deploys in fifteen minutes. This is the single highest-leverage habit in agency GoHighLevel work.

Naming Conventions Matter

Use lowercase with underscores and stay consistent. business_phone, not Business Phone in one place and phone_no in another. When you are three snapshots deep and handing over to a team member, consistent naming is what makes the account legible.

Custom Fields: Contact-Level Data

Custom fields live at Settings → Custom Fields, and each belongs to an object — most commonly Contact, but also Opportunity and Company.

Field Types and When to Use Them

• Single line text — names, reference numbers, short free text.
• Multi line text — notes, enquiry descriptions.
• Number — quantities, values, scores. Use this rather than text if you ever want to compare or sort.
• Date — renewal dates, appointment anniversaries, policy expiry. Critical for time-based automation.
• Dropdown / radio — a fixed list of options. Always prefer these over free text for anything you will segment on.
• Checkbox — multiple selections from a list.
• Monetary — deal values, quoted amounts.
• File upload — documents collected through forms.

The type choice matters more than people expect. Store a renewal date as text and you cannot build a workflow that fires 30 days before it. Store it as a date field and you can — which is the entire basis of renewal automation for insurance agents and subscription businesses.

Use Dropdowns, Not Free Text

If you plan to segment on a field, constrain it. A free-text “service required” field will accumulate “roof repair”, “Roof Repair”, “roofing”, “roof” and “reroof” — five values that your workflow conditions will treat as five different things. A dropdown gives you clean segmentation forever.

Date Fields: The Automation Unlock

Date custom fields deserve special attention because they enable a class of automation most accounts never build.

With a date field populated, you can trigger workflows relative to it: 30 days before a policy renewal, 12 months after a service, seven days before a contract ends, on a birthday. In the workflow builder, use the Contact Date Reminder-style trigger, point it at your field, and set the offset.

Practical examples:

• A med spa texting clients six weeks after a treatment to rebook.
• A roofing company following up 11 months after install for a maintenance inspection.
• An insurance broker starting a renewal sequence 45 days out.
• A gym re-engaging members 30 days after their last visit.

None of this is possible if the date is stored as text.

Where You Can Use Them

Both types work as merge tags across the platform:

• Email and SMS bodies and subject lines
• Funnel and website page content
• Workflow internal notifications and tasks
• Form and survey pre-fill
• Invoice and proposal templates
• Calendar confirmation and reminder messages
• Webhook payloads sent to external systems

Always set a fallback where the platform allows it. A message that opens “Hi ,” because the first name is blank looks worse than one that opens “Hi there” — configure the default rather than assuming the data is complete.

A Clean Setup Checklist

1. Audit what exists. Most inherited accounts have duplicate fields created by different people. Consolidate before building.
2. Agree naming conventions and write them down.
3. Create custom values first, before building any templates.
4. Define custom fields from your actual segmentation needs, not speculatively. Fifty unused fields make the contact record unusable.
5. Use dropdowns for anything you will filter on.
6. Map form fields to custom fields explicitly — an unmapped form field captures data nowhere useful.
7. Document the schema so the next person can work in the account.

Common Mistakes

• Using a custom field for business data. Storing the business phone on each contact means updating thousands of records to change one number.
• Hard-coding anything. If it might change, make it a custom value.
• Free text where a dropdown belongs. Unsegmentable data is only slightly better than no data.
• Wrong field type. Dates as text and numbers as text both break automation and reporting.
• Creating fields nobody fills. Every field should have a defined source — a form, an integration or a workflow.
• Renaming fields after templates reference them. Check what depends on a field before changing it.

A Field Naming Standard You Can Adopt

Consistency matters more than the specific convention. If you do not already have one, this works:

• Lowercase with underscores throughout — renewal_date, never Renewal Date.
• Prefix by domain where an account has many fields — policy_renewal_date, job_install_date, member_last_visit.
• Suffix by type for dates and amounts — _date, _amount, _count. This makes the schema readable at a glance.
• Avoid abbreviations that only make sense to whoever created them.
• Never include a client or brand name in a field that will travel in a snapshot.

Auditing an Account You Inherited

Taking over an existing GoHighLevel account usually means inheriting a field schema built by three different people. Before building anything new:

1. Export the field list and read it properly.
2. Find the duplicates. phone2, alt_phone and secondary_phone are almost certainly the same idea three times.
3. Find the empty ones. A field with no data and no source is dead weight — check nothing references it, then remove it.
4. Find the wrong types. Dates stored as text are the common one, and they silently prevent date-based automation.
5. Check what references each field before renaming or deleting anything. Workflows, forms and templates all break quietly.
6. Consolidate carefully. Migrate data into the surviving field before deleting the duplicate, not after.
7. Write the schema down so the next person inherits documentation rather than archaeology.

This is unglamorous work that pays for itself the first time you build a segment that actually returns the right contacts.

Frequently Asked Questions

Can a custom value differ per sub-account?

Yes — that is the point. Custom values are defined per sub-account, so the same snapshot deployed to ten clients produces ten correctly branded systems. See our sub-accounts guide for how this fits into agency structure.

Can I bulk update a custom field across many contacts?

Yes, through a filtered contact view and a bulk action, or through a workflow with an update action. For large or conditional updates, the API is more reliable.

Do custom fields transfer in a snapshot?

Field definitions transfer; contact data does not. You get the empty schema in the new sub-account, which is exactly what you want.

Is there a limit on how many I can create?

Limits are generous enough that they are rarely the constraint. Usability is the real limit — an account with 80 fields is one nobody can navigate.

What happens if a merge tag has no value?

It renders empty unless you set a fallback. Always set fallbacks on anything customer-facing.

Start Here

If you take one thing from this guide: before you build another template, create your custom values and reference them everywhere. It costs twenty minutes now and saves a day on every future deployment.

GHL Nexa builds snapshot-ready GoHighLevel accounts with the value and field schema set up properly from the start. If you have inherited an account that needs untangling, send us a message.

This guide is part of our GoHighLevel for Agencies series — agency playbook covering the whole topic.