GoHighLevel merge fields let a message retrieve data from a contact, appointment, user or location at the moment it is used. Custom values serve a different purpose: they store reusable business information, such as a company phone number, booking link or standard disclaimer, so that information can be maintained in one place.
The practical value is not personalisation by itself. The value is reducing repeated editing while keeping messages, pages and workflows aligned with the data they depend on. A merge field is useful only when the source record contains the right information and the workflow has a sensible response when it does not.
This guide explains the difference between merge fields and custom values, how to insert them in GoHighLevel, and how to design a safer process for testing, ownership and ongoing maintenance.
Merge fields and custom values solve different problems
Although GoHighLevel often presents merge fields and custom values in related menus, they should not be treated as interchangeable.
Merge fields
A merge field retrieves information from a specific record or system context. Examples include a contact’s first name, email address, appointment time, assigned user or location name. The result can change for every recipient.
Custom values
A custom value stores information that should be reused across multiple assets. Examples include a general phone number, office address, support email, booking URL or approved disclaimer.
This distinction creates a useful decision rule: use a merge field when the value belongs to the person or event being processed; use a custom value when the value belongs to the business, location or operating process.
A dynamic message is only as reliable as the data source, fallback logic and owner responsible for keeping that source accurate.
What GoHighLevel merge fields can represent
Available fields depend on the asset, account context and current GoHighLevel interface, so the insertion menu is the most reliable reference for a particular message. Common categories include:
- Contact data: first name, last name, email, phone number, company and custom contact fields.
- Location data: business name, address, phone number, website and other sub-account information.
- Appointment data: appointment date, time, calendar, meeting link, location and assigned user where supported.
- User data: team member details used in internal notifications or assigned-owner communication.
- System or workflow context: values made available by the specific message, trigger or automation step.
A contact field and a location field may look similar in a message, but they have different ownership. A contact’s phone number belongs to the contact record. A location’s phone number belongs to the business or sub-account. Mixing those sources can produce messages that appear personalised but contain the wrong information.
Custom contact fields are not the same as custom values
This is another important distinction. A custom contact field stores information that varies from contact to contact, such as an account reference, service preference or qualification detail. A custom value stores reusable information that is usually shared across many messages or pages.
For example, a customer’s preferred service might belong in a custom contact field. The general scheduling link for the business might belong in a custom value. Choosing the wrong storage location makes reporting, updates and ownership harder later.
Where to use merge fields and custom values
GoHighLevel commonly makes dynamic values available in email content, SMS messages, workflow actions, appointment communications, funnels, websites, forms and internal notifications. Availability can vary by builder and field type, so do not assume that a variable supported in an email is supported in every page element or message format.
Useful applications include:
- Greeting a contact using the name stored in the contact record.
- Adding appointment details to a confirmation or reminder.
- Displaying a location’s phone number or address across multiple pages.
- Using one booking link consistently in email, SMS and website content.
- Sending an internal notification that identifies the contact, owner or appointment involved.
Dynamic content should support a business decision or handoff. A contact name may improve clarity, while an appointment time may tell the recipient what action to take next. In contrast, adding a variable merely because it is available increases the number of points that can fail without improving the workflow.
Personalisation is useful when it clarifies the next action, confirms context or reduces manual correction. It is not a substitute for a well-defined workflow.
How to insert a merge field in GoHighLevel
The exact labels may change as GoHighLevel updates its interface, but the operating sequence is usually consistent.
Using the picker is safer than manually typing a variable. It reduces spelling errors and helps you select a field that is supported in the current context. If the variable appears as raw text, remains blank or displays unexpected data, inspect the source record and the location where the message is being rendered.
How to create and manage custom values
Custom values are most useful for information that appears in several assets and has a clear owner. Common examples include a general business phone number, office address, support inbox, scheduling link, social profile or approved legal wording.
- Open the relevant location or sub-account settings and find the area for custom values. The menu name and placement may vary with the current GoHighLevel interface.
- Create a descriptive name that explains both the value and its purpose. Names such as “Primary booking link” are easier to maintain than vague labels such as “Link 1.”
- Enter the approved value and confirm who owns future changes.
- Insert the custom value into supported emails, messages, pages or workflows using the available picker.
- Test the assets that depend on it, especially if the value is a URL, phone number or customer-facing disclaimer.
When a shared business detail changes, update the custom value rather than searching through every asset for hard-coded copies. This creates a single maintenance point, but it also creates a dependency. A wrong custom value can affect many customer touchpoints at once, so changes should be deliberate and reviewed.
Design rules for dependable dynamic content
1. Define the business state before adding the field
Start with the workflow state and recipient’s next action. For example, an appointment reminder may need the appointment time, meeting link and rescheduling instruction. It may not need every available contact field. This keeps the message focused and makes testing easier.
2. Decide what happens when data is missing
A blank first name, missing phone number or unavailable appointment link can make an automated message look broken. Before publishing, decide whether to use a neutral sentence, route the record for review, skip the message or require the field before the workflow proceeds. A fallback is part of the design, not an afterthought.
3. Keep ownership visible
Every important field should have an owner. Contact data may be maintained by a sales or service team. Location data may be maintained by an administrator. A booking link may be owned by the person responsible for scheduling. Without ownership, a dynamic system can preserve incorrect data very efficiently.
4. Separate shared values by location when required
Multi-location accounts need to distinguish global information from location-specific information. A shared agency value may be inappropriate when each location has a different address, phone number or booking process. Store information at the level where it is actually owned.
5. Test paths, not just templates
Test a complete workflow with representative records. Include a normal record, a record with missing optional data and, where relevant, a record associated with another location or appointment type. Check the subject, body, links, formatting, sender details and timing.
- Does each variable retrieve data from the intended source?
- Is the field populated for the records entering this workflow?
- Is there a clear fallback for missing data?
- Does the message still make sense when read by itself?
- Does the linked page, phone number or appointment detail work?
- Is there a named owner for future data or value changes?
A practical example of merge field design
Imagine a service business sending an appointment reminder. The contact record contains the customer’s name and phone number. The appointment record contains the date, time and meeting link. The location has the business name and support phone number. A useful reminder combines these sources only where each source has a clear job.
The message might address the contact by name, display the appointment time and include the meeting link. It could use a location custom value for support contact details. If the meeting link is missing, the workflow should not quietly send an incomplete reminder. It should use an approved fallback or create a task for review.
This example illustrates why a merge field is not simply a formatting feature. It is a dependency between a message and the record structure that supplies its data. If the workflow depends on accurate CRM fields, the CRM design and data-entry process need attention as well. For broader pipeline, ownership and data-structure work, see CRM consulting services.
Troubleshooting common problems
The placeholder appears instead of the value
Confirm that the field is supported in the asset, that a real record is available during rendering and that the relevant field is populated. Also check whether the message was previewed without selecting a record or test context.
The value is blank
Inspect the source record, not just the template. The contact may not have the field completed, or the appointment may not contain the expected detail. If blank values are possible, add fallback logic or change the workflow entry requirements.
The wrong business information appears
Check whether the message is using a contact, user, agency or location field. In multi-location setups, confirm that the workflow is running in the intended sub-account and that shared values have not been used where location-specific values are required.
A link or phone number is outdated
Find out whether the value is hard-coded in multiple assets or managed as a custom value. Centralise genuinely shared information, assign an owner and test the assets affected by future changes. If GoHighLevel is connected to other systems, review the handoff rather than adding more duplicate fields. Integration work may require a defined automation design, such as the approach described in Zapier automation services.
A custom value reduces editing effort, but it does not remove the need for governance. Centralised data still needs a clear owner, approved format and change process.
Use dynamic data as part of a wider operating system
Merge fields and custom values work best when they sit inside a clear process. First define the business state and the message’s purpose. Then identify the source of each value, assign ownership, decide how missing data is handled and test the complete path. Only after those decisions should you add more automation or AI.
More variables do not automatically create a better customer experience. Reliable GoHighLevel communication comes from accurate data, visible ownership and workflows that represent real business states. When those foundations are sound, merge fields can reduce manual work while keeping emails, SMS, pages and internal notifications consistent.
Frequently asked questions
What is the difference between a GoHighLevel merge field and a custom value?
A merge field retrieves data from a specific contact, appointment, user or location context. A custom value stores reusable business information, such as a phone number, booking link or disclaimer, for use across multiple assets.
Why is a GoHighLevel merge field showing as blank or raw text?
The source record may not contain a value, the field may not be supported in that asset, or the message may have been previewed without a valid contact or workflow context. Test with a populated record and confirm the field is supported.
Should a business phone number be a merge field or a custom value?
A general business phone number is usually best stored as a custom value because it is reused across many assets. A contact's personal phone number belongs in the contact record and is retrieved with a contact merge field.
How should merge fields be tested before activating a workflow?
Test the complete workflow with representative records, including a normal record and one with missing optional data. Check the rendered message, links, appointment details, sender information and fallback behaviour.
Can custom values be different for different GoHighLevel locations?
They can be managed at the relevant account or location level where supported. Use location-specific values when branches or brands have different contact details, booking links or operating information.
Make GoHighLevel data work as part of a reliable process
If merge fields, custom values and workflows are producing inconsistent results, ConsultEvo can help clarify the data model, ownership rules and automation logic before more tooling is added.
