GoHighLevel Custom Values: The Hidden Lever for Reusable Snapshots (2026)

If you build GoHighLevel snapshots for a living, you already know the tedious part: every time you deploy to a new client sub-account, something needs editing. The booking link in the nurture sequence. The business name in the welcome SMS. The support email buried in seventeen workflow emails. Multiply that across funnels, calendars, pipelines and Conversation AI prompts, and a "five-minute deployment" quietly becomes a two-hour find-and-replace exercise. The fix is not discipline. The fix is architecture, and the lever most agencies underuse is Custom Values.

Custom Values are account-level variables you define once per sub-account and reference everywhere through merge tokens. Set {{custom_values.business_name}} once, and every email template, SMS, funnel headline and workflow that references it updates instantly. Done properly, this turns a snapshot from a static template into a configurable system. In our agency builds, a well-designed Custom Values layer is the single biggest determinant of how fast and how cleanly a snapshot deploys. Below I will clarify what Custom Values actually are, how they differ from custom fields, which ones to standardise, and the mistakes that trip people up.

Custom Values vs custom fields: a distinction that matters

These two get conflated constantly, and the confusion produces broken snapshots. They are not interchangeable.

Custom Values are account-level constants

A Custom Value is a single variable that holds one piece of data for the entire sub-account. The business name, the main booking link, the support email address — these are the same regardless of which contact you are talking to. You set them under Settings > Custom Values, and you reference them with the {{custom_values.field_name}} token. There is exactly one value per sub-account, and changing it in one place propagates everywhere.

Custom fields are per-contact data

A custom field stores information that varies from contact to contact: a lead's preferred appointment time, their suburb, their package tier, the name of their pet for a vet clinic. You reference these with contact tokens like {{contact.first_name}} or {{contact.custom_field_name}}. Every contact carries their own value. If you are still deciding when to use a field versus a tag for segmentation data, our breakdown of tags vs custom fields is worth a read before you build.

The rule of thumb: if the data describes the business, it belongs in a Custom Value. If it describes the contact, it belongs in a custom field. The moment you hardcode a business detail into a template instead of tokenising it, you have created a maintenance liability that follows the snapshot into every deployment.

Why Custom Values make snapshots portable

Here is the mechanism that makes this powerful. When you load a snapshot into a fresh sub-account, GoHighLevel carries the Custom Value keys across, but the values are blank or set to a default. Your onboarding then becomes a single configuration screen: you fill in the business name, the booking link, the office hours and the sender name once, and every asset that references those tokens is now correct.

Compare that to a snapshot built with hardcoded details. There, deployment means opening each email template, each SMS step in every workflow, each funnel section, and each Conversation AI prompt to hunt down and replace the demo business name. That is where deployment errors creep in — a forgotten step in a rarely-triggered workflow sends "Welcome to Demo Clinic" to a real lead three weeks after launch. A clean Custom Values layer eliminates that entire class of error. If you want the broader deployment picture, see our guide on how to deploy and update snapshots across sub-accounts.

This pairs naturally with SaaS Mode. When you are onboarding clients at volume, the less manual configuration each sub-account needs, the more your fulfilment scales. A snapshot where 90 per cent of the personalisation lives in a dozen Custom Values is a snapshot a junior team member — or an automated onboarding workflow — can deploy without touching a single template.

The Custom Values worth standardising in every snapshot

Not every Custom Value belongs in your base snapshot, but a core set should appear in every build you ship. Standardising the keys means your templates, workflows and funnels reference the same tokens regardless of which client snapshot you are working from. Here is the baseline set we standardise across our agency builds.

Keep your naming convention consistent and lower-case with underscores. A predictable key like business_name is far easier to reference and audit than a free-typed label, and it keeps your token references identical across every snapshot you maintain.

Using Custom Values inside Workflows

Custom Values are not limited to static text in templates. You can reference them inside Workflow actions — email and SMS bodies, internal notification steps, and even some condition logic. This is where the portability pays off most, because workflows are the hardest assets to manually edit during deployment.

A practical example: a lead-nurture workflow that sends a reminder SMS reading "Hi {{contact.first_name}}, your consult with {{custom_values.business_name}} is confirmed. Reschedule here: {{custom_values.booking_link}}". That single message is fully portable — the contact token personalises per lead, the Custom Value tokens configure per sub-account, and you never touch the workflow during onboarding. If you are mapping out which triggers fire these messages, our complete workflow triggers reference covers the entry points worth wiring up.

Common mistakes to avoid

• Hardcoding business details into templates. Every demo business name, booking URL or support email typed directly into an email or SMS is a deployment landmine. Tokenise it from the start.
• Inconsistent key naming across snapshots. If one snapshot uses booking_link and another uses calendar_url, your templates are no longer interchangeable. Lock a naming convention and enforce it.
• Confusing Custom Values with custom fields. Using {{custom_values.first_name}} when you mean {{contact.first_name}} will send blank or wrong data to every contact. Business data is a Custom Value; contact data is a custom field.
• Forgetting to populate values after deployment. The snapshot carries the keys, not the values. A booking link left blank silently breaks every reminder. Build a post-import checklist or onboarding workflow that confirms each value is set.
• Putting URLs that change per client into the base snapshot as fixed text. Booking links, payment links and tracking URLs must be Custom Values, never baked-in constants.
• Over-tokenising trivial copy. Not everything needs a Custom Value. Reserve them for data that genuinely varies per sub-account, or your configuration screen becomes its own maintenance burden.

If you want snapshot architecture that scales cleanly across every client sub-account, book a strategy call with the HL Growth Partner team.

Book Your Strategy Call →

Frequently asked questions

What is the difference between a Custom Value and a custom field in GoHighLevel?

A Custom Value is an account-level variable that holds one piece of data for the whole sub-account, such as the business name or booking link, referenced with {{custom_values.field_name}}. A custom field stores data that varies per contact, such as a lead's suburb or appointment preference, referenced with {{contact.field_name}}. Business data belongs in Custom Values; contact data belongs in custom fields.

Do Custom Values carry across when I load a snapshot into a new sub-account?

The Custom Value keys carry across with the snapshot, but the actual values are blank or set to a default. You populate them once per sub-account during onboarding, and every template, workflow and funnel that references those tokens updates automatically.

Can I use Custom Values inside Workflows?

Yes. You can reference Custom Value tokens inside Workflow email and SMS bodies, internal notifications and some condition logic. This is where portability matters most, because it means you never have to manually edit workflow steps during deployment.

How many Custom Values should a snapshot include?

Standardise a core set — business name, booking link, support email, sender name, office hours, address and support phone — in every base snapshot, then add client-specific values as needed. Reserve Custom Values for data that genuinely varies per sub-account so your onboarding configuration stays manageable.

Why is my Custom Value showing as blank in sent messages?

The most common cause is that the value was never populated after the snapshot import — the key exists but holds no data. Check Settings > Custom Values for the sub-account and confirm each field is filled. The second most common cause is a typo in the token or using a {{custom_values.}} reference where a {{contact.}} field was intended.