How to Use GoHighLevel Custom Values in Documents and Contracts

What GoHighLevel custom values do in documents

A GoHighLevel custom value is a dynamic reference to data held elsewhere in the platform. In a document template, it acts like a merge field. When the document is generated, GoHighLevel attempts to replace that reference with data from the relevant record.

Depending on the template and account configuration, the source may be a standard contact field, a custom contact field, an opportunity field, an appointment value, or another supported record. The exact labels and available options can vary by feature version and account context, so use the value picker in the document editor where one is available rather than relying on a token copied from an unrelated template.

Custom values are useful for information such as a contact name, email address, company name, contract start date, appointment date, or opportunity amount. They should not be used to hide unclear business logic. Before inserting a value, decide which record owns it, when it becomes available, and what should happen if it is blank.

Custom values, custom fields, and document fields are different

These terms are related but not interchangeable:

A custom value connects the source to the template. A date field does not automatically make an arbitrary text value into a valid date, and a populated CRM field does not guarantee that it will appear unless the document field is mapped or inserted correctly.

Prepare the data before editing the template

Preparation is usually more important than the insertion step. Review the record structure before building the document:

• Identify the record that owns each value, such as the contact, opportunity, appointment, or location.
• Confirm the field has a single purpose and a clear name.
• Decide whether the value is required before document creation or only before signing.
• Check that date fields contain dates rather than informal text descriptions.
• Choose a test record with realistic data, including long names and populated optional fields.

Do not create several custom fields that represent the same business fact with slightly different names. For example, separate fields called “Start Date,” “Project Start,” and “Agreement Date” can create uncertainty about which value belongs in a contract. Establish one source of truth where possible, then use that source consistently in the template and related workflows.

How to link a custom value to a text field

Use a text field when the document needs names, addresses, identifiers, descriptions, or other text-based information.

1. Open the document template. Go to the Documents or Contracts area in GoHighLevel and open an existing template or create a new one.
2. Add or select a text field. Place the field where the value should appear and adjust its size and position.
3. Open the value or merge-field picker. Select the relevant source category, such as contact, opportunity, appointment, location, or custom fields.
4. Choose the precise value. Select the field that matches the intended business meaning. Similar labels should not be treated as interchangeable.
5. Combine dynamic and fixed text when useful. A sentence may contain both a static phrase and a contact or opportunity value. Keep the static wording stable and let the CRM supply only the variable information.
6. Save and generate a test document. Review the rendered document, not only the editor preview.

For example, a contract introduction might use a contact name and company field within fixed wording. The template should not contain a manually typed customer name, because that creates a maintenance problem when the document is reused.

Text field checks

• Confirm the value is connected to the intended record.
• Check whether the field is blank on the selected test record.
• Review spacing, line breaks, and field width after replacement.
• Check long values such as legal names or addresses for clipping.
• Decide whether a blank value should stop document creation or display an empty space.

How to link a custom value to a date field

Date fields need additional care because a date has both a business meaning and a display format. “Contract date,” “signature date,” “service start date,” and “appointment date” may all be different values even when they appear in similar places.

1. Add a date field. Place it near the clause, signature area, or schedule that depends on the date.
2. Define what the date means. Label it according to the event it represents, not merely its position on the page.
3. Map or insert the supported date value. Use the field configuration or value picker provided in the document editor. Available mapping options can depend on the document feature and record context.
4. Set editability deliberately. If the date comes from an approved CRM record, consider whether the recipient should be able to change it. If the signer must supply the date, leave it as an input rather than treating it as an imported value.
5. Review the display format. Use a format that is unambiguous for the people reading the document, especially when parties may interpret month and day positions differently.
6. Generate a test document. Use a record with a known date and verify both the value and its presentation.

A date field should represent a meaningful event in the process. It should not be used as a general-purpose text box containing phrases such as “as soon as possible” or “to be confirmed.” If the business process has not established the date, the correct outcome may be a required input or a controlled exception, not an empty automated value.

A practical testing sequence

Testing should verify the connection between the record, the value, the document field, and the final output. Use this sequence for every important template:

For a recurring process, record the source field, document field, required status, and owner in an internal procedure. This makes future template changes safer and gives the team a shared way to diagnose failures.

Common failure points and how to diagnose them

The value is blank

Start with the source record. A blank result may simply mean the field is empty, the value belongs to a different record type, or the document was generated before the data was saved. Confirm the record context and create a new test document.

The wrong value appears

Compare the selected field with the field label and business definition. Duplicate custom fields are a frequent cause of incorrect output. Also check whether the document is being generated from an opportunity while the value was stored only on a contact, or the reverse.

The date is present but confusing

Check the event represented by the source field and the display format. A correctly mapped appointment date is still wrong if the contract requires a signature date. Make the distinction explicit in field names and instructions.

The token or placeholder remains visible

Review how the value was inserted. A manually typed token may not be supported in the specific field or document context. Prefer the editor’s supported picker or mapping controls, then save the template and generate a fresh document.

The document layout breaks

Test with the longest realistic name, address, and company value. Resize fields and review line wrapping. Automation does not remove the need for document design.

Use custom values as part of a controlled workflow

Custom values solve data entry, not process ambiguity. If a document can be generated before an opportunity is qualified, a start date is approved, or a required field is reviewed, the template may produce a technically complete but operationally wrong document.

A sensible sequence is to define the business state that permits document creation, validate the required data, generate the document, assign ownership for review, and then send it for signature or completion. The CRM should make that state visible through fields, stages, tasks, or workflow conditions.

For broader pipeline ownership, field design, and integration decisions, see ConsultEvo CRM consulting. If document creation depends on connected tools, the same process-first approach can be applied through Zapier workflow automation. More automation steps are not automatically better. Each step should have a defined trigger, owner, and expected business result.

Example: a service agreement with contact and opportunity data

Imagine a service business that creates an agreement after an opportunity reaches an approved stage. The contact record supplies the signer’s name and email. The opportunity supplies the agreed amount and service package. A controlled custom date field supplies the planned start date.

The template can place those values in the relevant text and date fields, but the workflow should also define what happens when the start date is missing or the opportunity amount has changed. The document owner reviews the generated output before sending it. If the process cannot answer who resolves a missing value, the automation is not ready, regardless of whether the fields technically populate.