Custom values vs custom fields in GoHighLevel, and the layer that makes a snapshot reusable

Two features with similar names, doing completely different jobs, and mixing them up is the reason some snapshots load cleanly into a new sub-account while others need forty edits before they can send a single message.

The distinction in one line:

• A custom field stores something about a contact. It is different for every person.
• A custom value stores something about the business. It is the same for everyone in that sub-account.

Custom fields, properly

A custom field is a column on the contact record. Property type, policy renewal date, vehicle registration, treatment plan stage, preferred groomer. You create the field once, and then every contact has their own value in it — usually empty until a form, a workflow or a person fills it.

Custom fields are used for:

• capturing what a form submission told you
• branching a workflow on something specific to that person
• segmenting a list
• personalising a message with that person’s own detail

They travel in a snapshot as structure: the field definitions come across, the per-contact data does not. That is correct behaviour — you do not want another client’s contact data — but it means a workflow that branches on a field will land in the new account with the branch intact and nothing to branch on until real contacts arrive.

The field trap

Two fields with the same label in different accounts are not the same field. Each has its own internal identifier. If you build integrations or API calls against a field, reference the identifier, not the label, and expect it to differ per sub-account. Anyone who has written a webhook that worked in the account it was built in and silently wrote nothing everywhere else has learned this the expensive way.

Custom values, properly

A custom value is a named string set once for the whole sub-account, and referenced anywhere the account writes text: SMS bodies, email templates, funnel copy, workflow messages, calendar descriptions.

Business name. Office phone. Booking link. Review link. Address. Opening hours. Owner’s first name. Emergency-call promise. Service area. The name of the thing the business sells.

Change the value in settings and every message that references it changes. That is the entire feature, and it is the single most important one for anybody running more than three sub-accounts.

Why this is the difference between a reusable snapshot and a rebuild

Consider two snapshots that look identical in a demo.

Snapshot A has the business name typed directly into thirty-one message bodies. Loading it into a new account means opening thirty-one assets, finding the string, and replacing it — and the one you miss goes out in an SMS with the wrong company name on it.

Snapshot B has one custom value called Business Name, referenced thirty-one times. Loading it means filling in one field.

Both are “a snapshot with the same nine components”. Only one of them can be loaded forty times. This is why our note on what is inside a good GoHighLevel snapshot treats the custom-value layer as the first thing to inspect before buying anything.

A convention that holds up

Custom values become unmanageable at around thirty if you do not name them deliberately. The convention we use:

• Group by prefix. Biz –, Booking –, Review –, Offer –, Legal –. The settings list is alphabetical, so the prefix is the grouping.
• Name the fact, not the usage. Biz – Office Phone, not Phone For SMS Footer. The same fact gets used in places you have not thought of yet.
• One value, one fact. Never store Mon–Fri 8am–6pm, Sat 9am–1pm in a value called Hours if any message ever needs only the weekday part.
• Prefix anything with legal weight. Legal – Consent Line, Legal – Business Legal Name. When the compliance registration in A2P 10DLC registration requires an exact legal name, you want exactly one place that holds it.
• Order the load sheet by dependency, not alphabetically. The person filling them in should be able to work top to bottom.

The same discipline that applies to workflow and tag names applies here, and for the same reason — see naming conventions that survive a second builder.

Which one do I use? A decision test

Ask one question: would two different contacts in this account ever need a different answer?

Yes → custom field. No → custom value.

It resolves nearly every case in a second. A few that trip people up anyway:

Thing you want to store	Field or value	Why
The client’s booking link	Value	Same for every contact
The contact’s preferred technician	Field	Differs per person
The name of this month’s offer	Value	Same for everyone, changes monthly
The date a policy renews	Field	Per person
The office address in an email footer	Value	Same for everyone
Which service the enquiry was about	Field	Per person
The number a workflow tells people to call	Value	Same for everyone

The two genuinely awkward cases are multi-location businesses and anything seasonal.

For multi-location, if one sub-account serves three branches, the branch address cannot be a single custom value. Either it becomes a field on the contact (set by the form that captured which branch they chose), or the business is really three sub-accounts. Deciding that late is expensive, which is why it is one of the questions in what a sub-account actually is.

For seasonal copy — the offer, the promotion, the current campaign name — a custom value is right, and the value becomes something you deliberately change on a schedule. Keep those in one prefixed group so a monthly refresh is a single screen rather than a hunt.

Agency-level values and where they help

Values can also be defined at agency level, inherited by sub-accounts. Useful for genuinely agency-wide facts — your support email, your terms URL, your brand name in white-label copy.

Be careful about what you put there. An agency-level value is a single point of change across every client, which is excellent for a support address and catastrophic for anything a client might want different. Rule of thumb: agency-level values are for facts about you, sub-account values are for facts about them. White-label branding is the main legitimate case, covered in white-label sub-accounts.

Testing the layer

Filling custom values in is not the same as verifying them. Before go-live:

1. Set every value, including the ones you think are unused.
2. Create a test contact you control.
3. Trigger one message from each channel — SMS, email, and anything the AI receptionist reads aloud.
4. Read the rendered output, not the template. A value referenced with a typo renders as nothing at all, and an empty string is invisible in a template and obvious in a message.
5. Deliberately blank one value and confirm the message looks wrong. If it still looks fine, that value is not actually wired up anywhere and you have found a stale reference.

Step 4 is the one people skip, and it is the one that catches Hi from , going out to four hundred contacts. It belongs in the same pass as the rest of your pre-launch checklist.

The short version

• Custom field: about a person. Structure travels in a snapshot, data does not.
• Custom value: about the business. Set once, referenced everywhere, filled at load time.
• A snapshot’s quality is largely a function of how much of its client-specific text lives in values rather than in message bodies.

Every kit in the snapshot catalogue ships with its client-specific strings pulled out into a named, prefixed custom-value set and a load sheet that lists them in filling order — which is the difference between a kit you load and a kit you edit.