Custom values vs custom fields in GoHighLevel: which one your snapshot should use

Every agency snapshot eventually hits the same wall. You built it inside one client's sub-account, so the clinic name is typed into forty SMS bodies, the booking link is pasted into six emails, and the owner's first name is sitting in a workflow notification. Then you load it into client number two and spend the afternoon hunting for the first client's details in places you forgot you put them.

The fix everyone reaches for is "use custom values." That is half right. The other half is knowing when the thing you are storing is not a custom value at all, because it belongs to a contact, not to the business. Put per-contact data into an account-level slot and the snapshot loads clean and then quietly misbehaves the first week it has real leads in it.

So this post is one rule, the reasons behind it, and the behaviors in HighLevel that make the rule matter more in a snapshot than in a single account.

The one-question rule

Ask of every piece of data: does this have one answer for the whole sub-account, or one answer per contact?

• One answer per sub-account goes in a custom value. Business name, main phone, address, booking link, review link, the owner's name, office hours, a support email, a brand color.
• One answer per contact or opportunity goes in a custom field. The service a lead asked about, their preferred location, an intake answer, a referral source, a deal's quoted amount.

That is the whole decision. Everything below is why it holds up, and the places in GoHighLevel where getting it backwards costs you.

What each one actually is

HighLevel's custom values settings article defines custom values as key and value pairs that are created once and reused throughout the platform, and notes that when you change the stored value, every place using that key reflects the change. They live in the sub-account under Settings, Custom Values. The how-to guide lists where they can be used: conversations, workflows, websites and funnels, email campaigns and templates (including color inputs), and the Social Planner, with the caveat that availability varies by feature.

Custom fields are a different kind of object. HighLevel's custom fields guide describes them as a way to store additional information about contacts or opportunities beyond the default fields. They come in types: short and long text, dropdowns, date pickers, phone, email, radio selects, checkbox groups, URLs and more. They attach to a record, so each contact carries its own answer.

Put plainly: a custom value is a sentence you wrote once for the business. A custom field is a blank on a form that every contact fills in differently.

Why this matters more inside a snapshot

In a single sub-account, a hardcoded business name is an annoyance. In a snapshot it is a defect you copy into every client you load.

HighLevel's snapshots overview lists Custom Fields, including Company custom fields, Custom Objects and Custom Values among the CRM and data structure a snapshot carries. It also lists what does not transfer: contacts, appointments, conversations and messages, among others. So the shape of your data travels, and the records do not. That is exactly the split between the two features. A custom field definition arrives in the new account empty, waiting for contacts to fill it. A custom value arrives holding whatever you typed in the source account.

That second part is the trap. Every custom value in your snapshot shows up in the new client's account still saying the last client's phone number until somebody changes it. The workflows that reference it do not know the difference. They will happily text a new lead the old clinic's number.

Which is why the practical snapshot rule has two halves. Template every business detail as a custom value so it is replaceable in one place. And treat "fill every custom value" as the first step after a load, before anything is published. If you want the broader version of what goes wrong when a snapshot lands, we wrote that up in why GoHighLevel snapshots break.

Getting it backwards, in both directions

Business data stored in a custom field

This one usually happens because someone wanted the clinic's address available as a merge field and created a contact field for it. Now the address lives on contacts. Every new lead has it blank, because no form ever asks a lead for the clinic's address. The SMS that says "we are located at" sends a gap. Someone notices, adds a workflow step to stamp the address onto every contact, and now you have a workflow whose only job is to copy a constant into thousands of records, and a second place to update when the clinic moves.

The tell: a custom field that should hold the same value on every single contact. That is a custom value wearing the wrong costume.

Contact data stored in a custom value

The reverse is rarer and nastier. HighLevel has a workflow action, Update Custom Value, that replaces an existing custom value with a static value or a variable. The documentation notes the custom value must be in the same sub-account as the workflow, and that the change cannot be reversed. It reads like a convenient place to park something, so people use it to store "the last service this lead asked about" and then reference it in the next message.

A custom value holds one answer for the account. In our reading of how that action works, writing to it changes the shared value everywhere the key is used, not just for the contact moving through the workflow. Two leads arrive a minute apart, the second overwrites the first, and the first lead's follow-up names the second lead's service. Nothing errors. HighLevel's own example for the action is account-level, a discount rate changing for a VIP campaign. If you are tempted to write per-contact data into a custom value, you want a custom field. Test it in a sandbox sub-account before you take our word or anyone else's.

The behaviors worth knowing before you build

Renaming a custom value does not change its key. The settings article says the key is generated from the name, and that changing the name later does not change the key. References keep working, which is good. But "Main Phone" can end up keyed as something older and unrelated, and the person maintaining your snapshot next year will not know which is which. Name it right the first time.

A custom field's object is permanent. HighLevel's custom fields guide says field objects cannot be changed after creation. A field built on the opportunity object stays an opportunity field. If you guessed wrong, you are recreating it, and a recreated field is a new field with a new identifier. Every workflow action that pointed at the old one is now pointing at nothing, which is the failure we covered in how invalid IDs kill GHL automations without showing an error.

Only contact fields reach forms and contact workflows. The same guide states that only contact fields appear in forms and contact workflows. If intake data needs to come in through a form, it has to be a contact field, not an opportunity field.

Blank values resolve as blank. HighLevel's merge fields and fallback values article says a valid field can still resolve as blank when the saved value is unavailable, and documents per-use fallback text for email. It describes fallbacks for email specifically and does not say they apply to SMS, so plan as if your texts have no safety net.

Workflows flag unknown values, not empty ones. The how-to guide notes that unrecognized or outdated values in workflow text fields are highlighted in red. That catches a reference to a key that does not exist. It does not catch a key that exists and holds nothing, which is the state every unfilled value is in right after a load.

Overrides on load are permanent. When you load a snapshot into an existing sub-account, HighLevel shows a conflict review where each conflicting item is either overridden (replaced with the snapshot version) or skipped (kept as it is). The article states the override cannot be undone through the snapshot load. HighLevel's documentation does not spell out how a conflicting custom value is handled, specifically whether override replaces the client's stored value with your template's. Assume it does until you have tested it, and choose Skip for custom values in any account that is already live.

A snapshot structure that loads clean

• One custom value folder for business identity. Name, phone, address, hours, owner name, booking link, review link, support email. The settings article notes each custom value sits in one folder at a time and folders cannot be nested, so keep it flat and obvious.
• Template text you cannot miss. Fill template values with something that would look wrong in a real message, so an unfilled one is caught in the first test send instead of by a patient.
• Custom fields only for things a contact or deal answers. If every contact would carry the same value, it is not a field.
• Contact object for anything a form collects. Decide the object before you create the field, because you cannot change it afterward.
• Every business detail in messages goes through a custom value. No hardcoded names, numbers or links in SMS, email or workflow notifications. Search the snapshot for the source client's name before you share it.

The day-one check after every load

After the snapshot lands and before any workflow is published in the new account: open Settings, Custom Values, and read every one. Anything still holding the source account's data or your template text gets replaced. Then send yourself one test of each message that references a custom value, by SMS and by email, and read what arrived rather than what the editor shows.

It takes a few minutes on one account. Across a portfolio it is the step that gets skipped, because nobody wants to open twelve sub-accounts to read the same settings page twelve times. That skipped step is how one client's phone number ends up in another client's reminder texts.

Doing the check across every sub-account

This is the kind of inspection GHL Command was built for. It runs from Claude on your own machine, connected to each sub-account you manage, so you can ask for every custom value across your locations and have Claude flag the ones that are blank or still carry the template's dummy text, and list each account's custom fields by object so the backwards cases above stand out. It reads, you decide what to change. The credentials stay on your computer, not on somebody's server, and it works across the portfolio rather than one account at a time, which is the argument we made for running a portfolio from one console.

Flat $97/mo, every sub-account you manage included, never billed per account.

Frequently asked questions

What is the difference between a custom value and a custom field?
A custom value is a key and value pair stored once per sub-account and reused across the platform, so there is one answer for the whole account. A custom field stores extra information on an individual contact or opportunity, so each record has its own answer. Business phone: custom value. The service a lead asked about: custom field.

Do snapshots include custom values and custom fields?
Yes. HighLevel's snapshot overview lists custom fields (including company custom fields), custom objects and custom values. Contacts and conversations do not transfer, so field definitions arrive empty while custom values arrive holding whatever was in the source account.

Does renaming a custom value break the places that use it?
No. HighLevel states that changing the name does not change the key, so existing references keep working. The name and key can drift apart, though, so name values carefully at creation.

What happens when a custom value is empty?
HighLevel documents that a valid merge field can resolve as blank when the saved value is unavailable. Email supports per-use fallback text. HighLevel does not describe the same fallback for SMS, so fill every value before publishing workflows in a new account.

Can a workflow change a custom value for just one contact?
Not in the way most people mean. The Update Custom Value action replaces the stored value in the sub-account and HighLevel notes it cannot be reversed. Because a custom value holds one answer for the account, use a custom field for anything that belongs to a single contact.