Custom Values in GoHighLevel: The Underused Feature That Saves Hours

What custom values actually are

Custom values in GoHighLevel are sub-account-level variables. Think of them as named constants you can reference in workflows, emails, SMS, and templates — values that are set once per sub-account and used everywhere.

Examples:

• {{custom_values.business_name}} → "Acme Solar"
• {{custom_values.support_email}} → "support@acmesolar.com"
• {{custom_values.booking_link}} → "https://acmesolar.com/book"
• {{custom_values.business_phone}} → "(555) 123-4567"

Anywhere you'd normally type the actual value, you reference the custom value instead. Update the custom value once, and every workflow, email, and template using it updates automatically.

Most operators use 2-3 custom values and miss the leverage. Used well, custom values reduce maintenance work by 5-10× and make snapshots actually portable.

---

Why most setups don't use them well

When you set up a single sub-account, hardcoding values is fine. "Hi from Acme Solar" works because there's one Acme Solar.

The problems start when:

• You build a snapshot and realize every workflow has the business name hardcoded into the email body
• The business changes phone numbers and you need to update 30 templates
• You add a new owner whose email needs to receive notifications across 20 workflows
• You manage multiple sub-accounts and copy-paste mistakes mean some have outdated info

Each of these is a moment where custom values would have prevented hours of cleanup. They're dramatically more leverage than they look like in the docs.

---

The categories of custom values worth setting up

A useful way to organize: think in tiers from most-shared to most-specific.

Tier 1 — Universal business identity:

• business_name — used in nearly every email, SMS, and template
• business_phone — main number
• support_email — destination for replies
• booking_link — calendar URL
• business_address — physical location if relevant
• business_website — main URL

Tier 2 — Branding and content:

• email_signature — the standard footer text
• unsubscribe_link — already handled by GHL but useful for plain-text contexts
• social_facebook, social_instagram, etc. — social URLs
• legal_name — official name if different from business_name

Tier 3 — Operations:

• owner_email — where notifications go
• support_phone — different from main if needed
• escalation_email — issue routing
• lead_routing_default — fallback rep

Tier 4 — Service-specific:

• service_offering — text describing primary service
• service_price_range — used in nurture content
• proposal_template_link — where the proposal lives

The first three tiers belong in nearly every sub-account. The fourth tier varies by business.

---

Where to use custom values

The patterns:

In email templates. Rather than typing "Hi from Acme Solar," type "Hi from {{custom_values.business_name}}." Every email template uses these references. When the company name changes (mergers, rebrands), update once.

In SMS messages. Same pattern. "Got a sec to chat about your project? — {{custom_values.business_name}} team."

In workflow notifications. Internal notifications to "the owner" should send to {{custom_values.owner_email}} rather than a hardcoded address.

In booking links shared in messages. "Here's my calendar: {{custom_values.booking_link}}" — when the calendar URL changes, you don't update 50 templates.

In nurture sequences. Content that needs to reference the business name, the offering, or the service area uses custom values throughout.

In landing pages and forms. Custom values can populate page content, form labels, and confirmation messages.

---

How to use custom values in snapshots

This is where the real leverage shows up.

Without custom values, when you deploy a snapshot to a new client, every workflow and template needs the source client's name, phone, address, etc. replaced. This is hours of error-prone work per deployment.

With custom values used consistently, deploying a snapshot becomes:

1. Import the snapshot
2. Update the 8-15 custom values to the new client's specifics
3. Verify by spot-checking a few outputs

What used to be a 4-6 hour deployment becomes 30-60 minutes. Multiply across 20 sub-accounts and the time savings are substantial.

The catch: this only works if the snapshot was built with custom values from the start. Retrofitting an existing snapshot to use custom values is more painful than building it correctly the first time. If you're building snapshots, build them with custom values from day one.

---

Practical naming conventions

Naming matters more than you'd think. A few rules:

Use snake_case. business_name, not BusinessName or Business Name. Easier to read, easier to copy.

Use clear nouns. owner_email is clearer than email_1. Six months later you'll thank yourself.

Group with prefixes for related values. social_facebook, social_instagram, social_linkedin. When you scan the custom values list, related items cluster.

Don't use abbreviations. business_phone is better than biz_ph. Search and readability win.

Document somewhere. A simple Notion doc that describes each custom value's purpose. Future-you (or new team members) shouldn't have to reverse-engineer what _var_3 means.

---

A specific example: the appointment confirmation email

Here's what this looks like in practice. A typical appointment confirmation email body:

Hi {{contact.first_name}},

Thanks for booking with {{custom_values.business_name}}. 

Your appointment is confirmed for {{appointment.start_time}}.

Need to reschedule? Use this link: {{custom_values.booking_link}}

Questions? Reply to this email or text us at {{custom_values.business_phone}}.

— The {{custom_values.business_name}} team

This template lives in the snapshot. When deployed to "Acme Solar," the custom values resolve to Acme's specifics. When deployed to "Bayside Roofing," they resolve to Bayside's specifics. Same template, different clients, zero edits required.

Without custom values, you'd be editing this template (and 30 others like it) for every client deployment.

---

What custom values can't do

Honest limitations:

They're sub-account-scoped, not contact-scoped. Don't try to use custom values for per-contact data — that's what custom fields are for. Custom values are for "values that apply to everyone in this sub-account."

They don't update automatically from external sources. If you want a custom value to reflect today's promotion, you'll update it manually or via API.

They have a soft cap on count. GHL doesn't enforce a hard limit but having hundreds of custom values gets unwieldy. Stick to 20-50 well-organized values.

Some places in GHL don't support them cleanly. Most automation actions, emails, and SMS support custom values. Some niche places (certain integration configurations, some legacy features) may not. Verify before depending on them in unusual contexts.

---

Migrating existing setups to use custom values

If you've already built a sub-account or snapshot with hardcoded values everywhere, the migration is straightforward but tedious:

1. List the values that should be variable. Walk through emails, SMS, workflows, templates. Identify hardcoded strings that should be custom values.
2. Create the custom values. Set them up in the sub-account.
3. Replace incrementally. One template at a time. Test each one after replacement.
4. Verify systematically. Send test emails, run test workflows, check outputs.

For an existing complex sub-account, this is a 4-12 hour project. For a snapshot serving multiple clients, the time savings post-migration are massive — usually paying for the work within the next 1-2 deployments.

---

When to use custom fields instead

Quick distinction since the names are similar:

• Custom values — sub-account-level variables (one value applies to everyone in the sub-account)
• Custom fields — contact-level data (different value per contact)

If the data varies per lead/client, it's a custom field. If it's the same across all contacts in the sub-account, it's a custom value.

A common confusion: some operators put company-wide info into custom fields and end up updating it on every contact. That's the wrong tool. Custom values handle this case in one update.

---

If you want help building snapshots and sub-accounts that use custom values to make deployment fast and maintenance easy, let's talk.