GoHighLevel Custom Values: Setup Guide (2026)

By Dr Priya Jaganathan, GoHighLevel Certified Admin · HL Growth Partner, Australia · Updated 30 August 2026 · 8 min read

GoHighLevel custom values are the single most underused feature in the platform, and they are the difference between an agency that onboards a client in an hour and one that spends three days rewriting emails. A custom value is a reusable variable stored at sub-account level — set it once, reference it everywhere.

I build and hand over sub-accounts for Australian service businesses every week, and the accounts that stay maintainable all have one thing in common: nothing hard-codes a booking link, a phone number or a price into an email body. This guide covers where custom values live, how the merge syntax works, how they travel inside snapshots, how to name them so they survive twelve months of edits, and the mistakes that quietly break live SMS campaigns.

What are GoHighLevel custom values?

A custom value is an account-level variable. You create it under Settings > Custom Values inside a sub-account, give it a name, and paste in the value. From then on you reference it anywhere the platform accepts merge fields — email builders, SMS bodies, workflow actions, funnel and website text elements, form and survey confirmation messages, and even URL fields.

The merge syntax is {{custom_values.key}}. So a custom value named "Booking Link" becomes {{custom_values.booking_link}}. GoHighLevel generates the key from the name you type, lowercasing it and replacing spaces with underscores. Most builders in the platform have a merge-field picker (usually a small tag or braces icon) that inserts the correct token for you — use it rather than typing tokens by hand, because a single character wrong renders as blank text, not an error.

Custom values versus custom fields

This trips up almost every new admin. The two things sound similar and behave nothing alike.

A custom field holds data that differs per contact: preferred appointment time, property address, dog's name, lead source detail. There are thousands of them in a busy database, one set per contact record, and they render through {{contact.field_name}}.

A custom value holds data that is the same for every contact in that sub-account: the business name, the support phone number, the review link, the current offer price. There is exactly one value per sub-account, and it renders through {{custom_values.key}}. If you find yourself pasting the same booking URL into fourteen emails, that is a custom value you have not created yet.

Why HighLevel custom values matter for snapshots

This is the real payoff. When you build a GoHighLevel snapshot and load it into a new sub-account, the snapshot carries the custom value keys — but the values come across empty or carry whatever was in the source account. You then fill them in once per client at onboarding.

That is the entire mechanism behind selling one snapshot to fifty clients. Your nurture sequence says "Book a time here: {{custom_values.booking_link}}" rather than a hard-coded calendar URL. Your review request SMS says "Leave us a review: {{custom_values.review_link}}". Your funnel footer says {{custom_values.business_name}}. Load the snapshot, spend twenty minutes filling a list of about twenty-five custom values, and every email, SMS, funnel page and workflow in the account is correctly branded without you opening a single builder.

Skip this and you get the scenario I have cleaned up more than once: an agency with eleven client sub-accounts, all running the same snapshot, all still sending clients to the original demo account's calendar because nobody remembered which of the sixty emails contained the hard-coded link.

Recommended custom value keys to set up

Here is the baseline set I load into every Australian sub-account. Adjust the values, keep the keys identical across accounts so your snapshot stays portable.

Naming conventions and folders

Use lowercase words separated by spaces when you create them (GoHighLevel converts to underscores), and prefix by category so the list stays scannable: Offer — Price, Offer — Expiry, Brand — Business Name, Compliance — SMS Opt Out. Custom values also support folders, so group them into Brand, Links, Offer, Compliance and Internal. A tidy list of forty values in five folders is workable; a flat alphabetical list of forty is not.

Decide the naming scheme before you build the snapshot, not after. Renaming a key later is the single riskiest thing you can do in this part of the platform — more on that below.

Using custom values in workflows

Inside a workflow, custom values behave as plain merge tokens in any text field:

• Send SMS / Send Email: body copy, subject lines and the from-name field all accept {{custom_values.key}}. This is where the compliance footer earns its keep.
• Internal notification: route alerts to {{custom_values.support_email}} instead of hard-coding a staff address that changes when someone leaves.
• Webhook: pass a custom value in the JSON payload — useful for sending the sub-account's business name or location identifier to Make, Zapier or your own endpoint so the receiving system knows which client fired the event.
• If/Else branches: you can compare against a custom value to switch behaviour per client. If you are building branching logic, my guide to GoHighLevel workflow if/else conditions covers how the operators actually evaluate.

In funnels, websites and trigger links

Funnel and website text elements accept the same syntax, which means a snapshot's landing pages can carry client branding without you editing a page. Button URLs accept them too — set the button destination to {{custom_values.booking_link}} and every page in the snapshot points at the right calendar.

You can also append custom values to URLs as query parameters, for example adding a campaign identifier to a link. This pairs well with GoHighLevel trigger links, where the tracked destination can itself be driven by a custom value so one snapshot's trigger links resolve correctly in every sub-account.

Compliance and deliverability uses

Two Australian-specific reasons to take this seriously.

First, SMS. Australian marketing messages need clear sender identification and a functional opt-out under the Spam Act, and A2P registration adds its own content expectations. Storing your opt-out wording and sender identification as custom values means you update the phrasing in one place if the rules or your registration copy change, rather than editing sixty SMS actions. My breakdown of GoHighLevel SMS A2P compliance in Australia goes through what the footer actually needs to say.

Second, email. Keep the sub-account's Mailgun sending domain recorded as a custom value so anyone doing a handover can see at a glance which domain the account authenticates through, and so internal alert emails can reference it. It is a documentation habit more than a rendering one, but it saves a support ticket every time. The mechanics of the sending setup are covered in my guide to GoHighLevel email deliverability with Mailgun.

How to test before you go live

Never trust a merge token you have not seen render. My routine:

1. Create a dummy contact with your own mobile and email — I keep one named "ZZ Test Contact" in every account so it sorts to the bottom of the list.

2. Run the workflow against that contact manually, or use the test feature in the workflow builder, and read the actual received SMS and email rather than the preview. Previews sometimes resolve tokens that fail in production.

3. Click every link in the received message. A booking link with a typo still looks like a link.

4. Check the funnel pages in a private browser window, because the builder preview can render differently from the published page.

If tokens come through blank or as raw text, the cause is almost always an empty value, a misspelt key, or a token typed into a field that does not support merge fields. GoHighLevel's own help centre documents which fields accept them, and my post on GoHighLevel workflow troubleshooting walks through reading the execution logs when something silently fails.

Build custom values into client onboarding

Make it a step in the process, not a thing you remember. In my onboarding workflow every new client sub-account triggers an internal task called "Set custom values" with a checklist:

Load snapshot → open Settings > Custom Values → work down the list top to bottom filling every empty value → send the test contact through the welcome sequence → publish. Twenty to thirty minutes if the client has already returned their intake form with their booking link, hours, phone, review link and offer details.

I collect all of that in the intake form itself, with the form field labels matching the custom value names, so filling them in is transcription rather than investigation. If you are on a plan where you are managing many sub-accounts, check the current GoHighLevel pricing tiers — snapshot-driven onboarding only pays off at volume, and the agency plans are priced accordingly.

Common mistakes to avoid

• Renaming a key after it is referenced. Every email, SMS, funnel and workflow still pointing at the old key breaks and renders blank. If you must rename, create the new key, update references, then delete the old one — never rename in place on a live account.
• Leaving values empty in a fresh sub-account. An empty custom value does not throw an error. It renders as nothing, so your SMS goes out reading "Book a time here: " with a trailing space, at scale, to real people.
• Using a custom value for per-contact data. If it changes between contacts it is a custom field. Putting a contact's appointment time in a custom value overwrites it for the entire account.
• Storing API keys and passwords in custom values. They are visible to anyone with sub-account access and travel in snapshots. Keep secrets out.
• Hard-coding "just this once". The one email with a pasted calendar link is always the one that ships to fifty clients pointing at your demo account.
• Not documenting what each value expects. Use the naming to signal format — "Offer — Price (include $)" beats a bare "price" that one VA fills as 149 and another as $149.00 inc GST.

Where tags fit alongside custom values

Custom values describe the account. Custom fields describe the contact. Tags describe what has happened to the contact. Keep the three cleanly separated and your automations stay readable a year later; blur them and you end up with tags carrying data and custom values carrying state. If your account has drifted, my GoHighLevel tags strategy post sets out a naming structure that works alongside the custom value conventions above.

The test I apply before creating anything: would this value be identical for every contact in this sub-account, and different in the next client's sub-account? If yes, it is a custom value. Build it once, reference it everywhere, and never paste a booking link into an email body again.

If you want your snapshot and custom values structured so every new sub-account onboards in under an hour, book a strategy call with the HL Growth Partner team.

Book Your Strategy Call →

Frequently asked questions

Where do I find GoHighLevel custom values in the platform?

Open the sub-account, go to Settings and select Custom Values from the left menu. You create, edit and folder them there. They are set per sub-account, so each client account has its own list even when they all came from the same snapshot.

Do custom values transfer when I load a snapshot?

The keys transfer, so every email, SMS, funnel and workflow that references them stays intact. The values themselves need to be set in the new sub-account at onboarding. That separation is exactly what lets one snapshot serve many clients without rewriting content.

What happens if a custom value is empty?

It renders as nothing at all — no error, no warning, no fallback text. A message reading "Call us on " goes out looking broken to the recipient. Always send a test contact through the sequence before you activate a workflow in a newly loaded sub-account.

Can I use custom values inside URLs and buttons?

Yes. Funnel and website button destinations, workflow SMS and email bodies, and query string parameters all accept them. Setting a button destination to a booking link custom value means the same snapshot page points at the right calendar in every sub-account.

Is it safe to rename a custom value key?

No, not on a live account. Renaming changes the merge token, and every place still referencing the old token silently renders blank. Create the new one, migrate the references, verify with a test send, then remove the old one.

Related articles

• GoHighLevel Snapshots: Create, Load and Update Guide (2026)
• GoHighLevel Workflow If/Else Conditions Guide (2026)
• GoHighLevel Trigger Links: Setup and Tracking (2026)
• GoHighLevel Workflow Troubleshooting: Fix Errors (2026)