GoHighLevel Custom Values: The Practical Guide

Two contacts book the same appointment type, and the confirmation email quotes two different prices — not because the CRM is broken, but because someone hardcoded “$149” directly into an email template eight months ago and the price has changed twice since. That’s the failure mode Custom Values exist to prevent. They’re one of the more under-explained parts of GoHighLevel to a new sub-account admin, and they get confused constantly with Custom Fields, which look similar in the settings menu but solve a completely different problem. This guide covers what a Custom Value actually is, the exact mechanics of the merge-tag syntax, how it differs from a Custom Field, common use cases, setup steps, folder organization, and the failure modes worth testing for before a value goes live in a client-facing message.

What is a GoHighLevel Custom Value, mechanically?

A Custom Value is a single named piece of data, stored once inside a sub-account (or, per a 2026 platform change covered below, at the agency/company level), that gets referenced anywhere in that account through a merge tag rather than typed out directly. Per GoHighLevel’s own support documentation on using Custom Values, the mental model the platform itself uses is closer to a programming variable than a form field: you define a Key and a Value once, and the Key becomes the thing you write everywhere the Value needs to appear.

The setup path is: Settings > Custom Values > Add Custom Value. You name the value (GoHighLevel generates a key from that name), enter the actual text, number or code that should display, optionally file it into a folder, and save. From that point, the value is available through the merge-tag picker in every editor across the sub-account — email builder, SMS composer, funnel and website builder, workflow action steps, and document/contract templates.

The syntax itself follows GoHighLevel’s broader handlebars-style merge-tag convention, the same {{ }} pattern used for contact and opportunity fields:

{{custom_values.support_phone_number}}
{{custom_values.current_promo_price}}
{{custom_values.booking_link}}

That’s structurally the same pattern as a standard contact merge tag like {{contact.first_name}} or {{contact.email}}, just under the custom_values namespace instead of contact. GoHighLevel’s merge fields and custom variables overview is explicit that these tags are case-sensitive — {{contact.email}} resolves correctly, but a miscapitalized {{Contact.Email}} does not. The same sensitivity applies to Custom Value keys, which is exactly why every editor ships with a built-in merge-tag picker rather than expecting you to type the tag from memory. Typing it by hand and getting one character wrong doesn’t throw an error — it just renders the literal tag text to the reader, which is a much harder bug to catch in QA than an outright failure.

Custom Values vs Custom Fields: the actual distinction

The two features sit next to each other in the settings menu, use visually similar merge-tag syntax, and get lumped together in a lot of secondhand tutorials — which is exactly why the confusion is so common. The distinction that actually matters is what shape the data has, not where it lives in the UI.

A Custom Field stores information that’s specific to one contact or one opportunity and genuinely differs from record to record: a birthday, a preferred communication channel, a lead source, a membership tier, a piece of intake-form data. Every contact has their own value for that field, and it’s edited on that individual contact’s or opportunity’s profile.

A Custom Value stores one piece of information that’s the same for every contact who sees it, referenced from a single stored location: a support phone number, a physical address, a current promotional price, a booking-calendar link, a standard legal disclaimer. There’s exactly one current value, and every email, SMS, funnel page or workflow step that references its tag shows that same value, because they’re all pointing at the same stored source rather than each holding their own copy.

The practical test: if the answer to “what should this say?” changes based on which contact you’re looking at, it’s a Custom Field. If the answer is the same regardless of which contact you’re looking at, and you’d rather edit it once than hunt down every place it appears, it’s a Custom Value. Getting this backwards is the root cause of two recurring setup mistakes: building a Custom Field for something that’s actually account-wide (creating unnecessary per-contact data entry for information that never varies), or hardcoding account-wide information directly into a template instead of using a Custom Value (which is the exact mismatched-price scenario this guide opened with).

Common Custom Value use cases

Business identity information is the most common starting point — business name, physical address, main phone number, support email, and business hours, referenced across every automated email footer, SMS signature and funnel contact block rather than typed once per template. When a business moves offices or changes its support number, updating one Custom Value fixes every place that information appears instead of triggering a manual find-and-replace across dozens of templates.

Booking and scheduling links are a close second. A Custom Value holding the current calendar or booking-page URL means a workflow, email and SMS sequence can all reference {{custom_values.booking_link}} instead of each hardcoding the URL — which matters the moment that calendar gets rebuilt or a new booking page replaces the old one, since only the Custom Value needs updating.

Dynamic pricing insertion is where Custom Values earn their keep for anyone running promotions or seasonal offers. A current price, discount percentage or offer name stored as a Custom Value and referenced across a funnel page, a cart-abandonment email and a follow-up SMS sequence lets a price change roll out everywhere the moment the stored value changes, rather than requiring someone to track down and edit every page and message that quotes the old number. This is also where the earlier mismatched-price scenario gets fixed structurally instead of by relying on someone remembering to update every template by hand.

Standard legal and compliance text — disclaimers, unsubscribe language variants, licensing numbers for regulated industries — benefits from the same single-source-of-truth logic, particularly for agencies managing multiple sub-accounts where consistent compliance language matters and manual copy-paste across accounts is exactly the kind of process that drifts out of sync over time.

Social media handles, review-site links and any other short reusable string that shows up in more than one template are lower-stakes but add up: the value of a Custom Value scales with how many places a given piece of information gets reused, not with how important any single instance of it is.

Setting up Custom Values: the actual steps

Inside a sub-account, navigate to Settings > Custom Values. Click Add Custom Value. Name it clearly and specifically — support_phone_main communicates more than phone2 when someone else is maintaining the account six months later. Enter the value itself: text, a number, a URL, or even a color code if you’re referencing brand colors inside a funnel template. Assign it to a folder if one exists for that category of value (business info, pricing, links), and save.

Settings > Custom Values > + Add Custom Value
  Name: Current Promo Price
  Value: $149
  Folder: Pricing
  → Save

Once saved, the value is immediately available through the merge-tag picker in every editor across the sub-account — no separate step needed to “publish” it to email versus SMS versus funnels. Per GoHighLevel’s Custom Values Settings documentation, folders can be renamed, searched, and used for bulk operations like moving or deleting several values at once, but folders can’t be nested inside other folders — it’s a flat organizational layer, not a full folder tree, so plan a naming or folder convention that doesn’t assume deeper nesting will be available later.

Editing an existing value works the same way in reverse: locate it in the Custom Values list, open the three-dot menu, choose Edit, update the value, and save. Every live reference to that value’s tag updates immediately across the account — there’s no republish or resync step for existing emails, workflows or funnels that already reference the tag, which is the core mechanic that makes Custom Values worth using over hardcoded text in the first place.

Folders and organization at scale

A sub-account with a handful of Custom Values doesn’t need much structure. An agency running Custom Values across a multi-location build, or a sub-account that’s accumulated fifty or sixty values over a year of campaigns, benefits from a folder convention set early rather than retrofitted later. A reasonable starting structure separates values by function — business identity, pricing and offers, links (booking, review, social), and legal/compliance text — since that grouping tends to match how someone searching for a specific value thinks about it (“I need the current promo price” points to the Pricing folder faster than an alphabetical list of forty ungrouped values does).

Because folders don’t nest, resist the urge to build an elaborate category tree that assumes sub-folders will be available — GoHighLevel’s settings UI supports one flat layer of folders, and a convention built around that constraint (four to eight top-level folders, clearly named) holds up better over time than a structure designed for deeper nesting the platform doesn’t support.

Custom Values and snapshots: the gap worth testing for

Custom Values interact with GoHighLevel snapshots in a way that catches new agency admins off guard. A snapshot bundles a sub-account’s pipelines, automations, calendars, forms and tags into a deployable template — the mechanism covered in detail in GoHighLevel Snapshots Explained — but snapshot export doesn’t reliably carry every dependency with it, and Custom Values are one of the pieces that can go missing in that export.

The practical failure mode: an agency builds a fully working sub-account, complete with populated Custom Values for business info, pricing and booking links, exports it as a snapshot, and deploys that snapshot to a new client’s sub-account. If the Custom Values didn’t carry over cleanly, every email and SMS template that references {{custom_values.booking_link}} or {{custom_values.support_phone_number}} goes live with a tag that resolves to blank text — not an error, just an absence, which is easy to miss in a quick visual check of the template but obvious the moment a real contact receives a confirmation email with a blank line where the booking link should be.

The fix is procedural, not technical: after deploying any snapshot to a new sub-account, explicitly check Settings > Custom Values against the source account’s list before the first live campaign or automation goes out, and re-create anything that’s missing. Treating snapshot deployment as complete without that check is the single most common way a new sub-account goes live with broken merge tags.

Testing before launch: the checklist worth actually running

Before any sub-account’s first real campaign or automation goes live, send a test version of every template that references a Custom Value to an internal inbox or phone number and visually confirm each tag resolved to real content rather than blank space or literal tag text. This matters more for Custom Values than for Custom Fields, since a Custom Field pulling blank data usually only affects one contact’s message, while a blank Custom Value affects every message that template sends until it’s caught.

Specifically worth checking: booking and calendar links actually load the right page, pricing figures match what’s currently being sold, phone numbers and addresses are current (especially after a snapshot deployment or a business relocation), and any legal or compliance text hasn’t reverted to a placeholder. None of this is complicated work, but it’s the kind of checklist step that gets skipped under launch-day time pressure, which is exactly when it matters most.

Company-level Custom Values: a 2026 update worth flagging carefully

Multiple secondary sources report that GoHighLevel extended agency-level Company fields into the Custom Values system during 2026, letting company-level data — the kind of information that lives at the agency rather than inside any single sub-account — resolve inside sub-account emails, workflows, contracts and Conversation AI through the same merge-tag mechanism. If accurate, that would mean an agency-wide piece of data (an agency’s own contact info, for instance) could populate consistently across every client sub-account without being re-entered account by account.

Worth being direct about the confidence level here: this detail comes from secondary GoHighLevel-adjacent blog coverage rather than being independently confirmed against GoHighLevel’s own primary support articles at the time of writing, and the specific rollout date circulating in that secondary coverage wasn’t verifiable against an official changelog. If a company-level Custom Values workflow is central to a multi-location or white-label build, confirm current behavior directly inside the account rather than building around an unconfirmed date — GoHighLevel’s Custom Values Settings support article is the primary reference to check against as this documentation gets updated.

Using Custom Values inside workflows, not just static templates

Custom Values aren’t limited to email and SMS copy — they’re available as an option inside workflow action steps too, which is where a lot of the account-wide consistency argument actually pays off. A workflow action that sends an internal Slack or email notification, updates a custom field, or posts to a webhook can reference a Custom Value the same way a template does, meaning the destination URL for an internal notification, the routing email address for a sales team, or a threshold value used in a condition step can all live in one place instead of being retyped into every workflow that needs it.

That matters most for agencies running the same automation logic across several sub-accounts. A round-robin lead-routing workflow that references {{custom_values.sales_team_email}} instead of a hardcoded address can be copied across client sub-accounts with only the Custom Value needing a per-client update, rather than opening the workflow builder and manually re-pointing every action step. It’s a smaller version of the same leverage a snapshot gives an agency at the account-structure level, applied at the level of a single value inside one workflow.

For anyone building on top of the API rather than only the visual workflow builder — covered in more technical depth in aibrevo’s GoHighLevel API integration guide — Custom Values are exposed as a queryable resource in their own right, distinct from the contact and custom-field endpoints. That separation in the API mirrors the conceptual separation covered above: a request against the Custom Values endpoint returns the account-wide key/value list, while a request against a contact’s record returns that contact’s individual Custom Field data. Treating them as two different data models in code, not just in the UI, avoids a class of integration bugs where a sync job tries to read account-wide pricing off a contact record that was never meant to hold it.

One more mechanical detail worth knowing before building anything that writes to Custom Values programmatically: because a Custom Value is shared across every reference to it, an automated process that updates one — say, a nightly job that refreshes {{custom_values.current_promo_price}} from an external pricing system — changes what every live template shows immediately, with no staging or preview step in between. That’s a feature when the goal is exactly this kind of centralized control, and a real risk if the update job has a bug, since a bad write propagates to every customer-facing message referencing that tag the moment it lands. Testing that kind of integration against a sandbox sub-account before pointing it at a live one is worth the extra step, the same caution that applies to any automated write against production data.

Where Custom Values fit into a broader setup

Custom Values are a small feature with outsized leverage on a build’s maintainability. A sub-account that hardcodes business info, pricing and links directly into templates works fine on day one and gets progressively harder to keep accurate as more campaigns, emails and funnels reference that same information independently — every future update becomes a manual search across an ever-larger set of templates instead of a single edit. Building the core Custom Values (business identity, pricing, key links) before the bulk of workflow and funnel building starts is a small amount of upfront setup that pays back the first time any of that information changes.

This is also one of the places where a professionally scoped GoHighLevel build differs from a rushed one — not in whether Custom Values get created at all, but in whether they get planned as infrastructure from the start versus retrofitted after a dozen templates already have the same string typed in by hand. For agencies managing this across several sub-accounts at once, HighLevel Automation Team’s GoHighLevel setup team handles the same groundwork across multi-location and multi-client builds, where a consistent Custom Values convention matters even more because it has to hold up across every sub-account it’s cloned into, not just one.

If Custom Values are already in place but workflows referencing them aren’t firing the way they should, GoHighLevel Workflow Not Triggering covers the more common causes on the automation side, separate from a merge-tag issue. And if the underlying question is less “how do I use this feature” and more “should we be managing this ourselves or bringing in a build partner,” aibrevo’s GoHighLevel implementation team scopes exactly this kind of account architecture — Custom Values, Custom Fields, snapshot structure — as part of a standard setup engagement, and GoHighLevel’s published implementation cost ranges break down what that typically runs.

The short version

A Custom Value is reusable, account-level data referenced by a {{custom_values.key}} tag and edited in exactly one place. A Custom Field is per-contact or per-opportunity data that legitimately varies record to record. Confusing the two — or skipping Custom Values entirely in favor of hardcoded text — is what turns a small pricing update into a multi-template search-and-replace project six months later. Set the core values up early, test every tag before a template goes live, and double-check them explicitly after any snapshot deployment, since that’s the single most common place they go quietly missing.