For agencies using GoHighLevel iMessage workflows, that check should include the outgoing webhook, not just the template preview.
Key takeaways
- Map each message detail to its source and the context needed to use it.
- Test missing data separately from unavailable appointment context.
- Approve the complete fallback message and inspect it before customer use.
What should you inspect before editing the template?
Start with a failed message and its workflow execution. Record the client sub-account, test contact, entry trigger, sending action and text that arrived. Keep the investigation tied to that execution so an unrelated successful preview does not hide the failure.
HighLevel says incorrect merge-field syntax and absent source data can cause problems. Its merge-field overview also states that merge fields are case-sensitive. Select the field from the available picker instead of retyping a similar-looking label.
Separate the symptoms in your notes:
- A gap where the name belongs: inspect the source and its availability.
- Visible braces or a field name: inspect whether the token was supported and resolved.
- A real but incorrect value: inspect the chosen record and mapping.
- Correct preview text but incorrect received text: inspect the actual send path.
These are investigation paths, not diagnoses. Preserve the original template and use a draft test workflow while identifying the cause.
How do you build a field-to-message check?
Create a worksheet for the message you are fixing. The following is a hypothetical test fixture, not a report of a client result. Replace the sample expectations with values from your own test records.
| Message detail | Source to inspect | Sample expectation | Execution check | Result to record |
|---|---|---|---|---|
| Greeting | Contact first name | Morgan | Correct contact selected | Name in final text |
| Business identity | Reusable account value | Example Service Team | Correct client account | Approved business label |
| Visit details | Appointment record | Scheduled visit date | Intended appointment available | Correct date in message |
| Meeting location | Appointment record | Office reception | Same appointment selected | Complete location wording |
| Entire message | Outgoing request body | Approved sentence | Correct sending action | Matches received text |
HighLevel distinguishes reusable Custom Values from record-specific Custom Fields. Appointment merge fields draw from appointment records, and available categories depend on the feature and context. See HighLevel’s Custom Values guide.
Add an owner beside each worksheet row. The person maintaining the form might own the name mapping, while the workflow builder owns appointment selection. This keeps a blank field from becoming an unresolved handoff between teams.
Mark each detail as required or optional for that specific message. A greeting can often omit a name. A reminder that tells someone when to arrive needs verified visit details.
How do you test whether contact data is missing?
Keep the workflow path fixed and change only the data under test. Use records controlled by your agency, with no customer enrollment.
- Open the exact test contact used by the workflow and inspect the source field.
- If a form supplies the value, submit a distinctive test value and check where it was saved.
- Run the populated record through the intended trigger and inspect the rendered message.
- Clear the optional test field and repeat through the same path.
- Confirm that the empty version takes the approved generic branch rather than producing broken wording.
Compare the form field’s destination with the token selected in the message. Similar display labels are not sufficient proof that they refer to the same stored value. Also check whether you are reviewing the record that actually entered the workflow.
A HighLevel community report about blank custom fields after form submission describes an email example. It supports investigating this symptom, but it does not establish an SMS defect or a confirmed cause in your account.
Avoid adding an arbitrary delay as the first repair. If execution history suggests the send precedes the field update, investigate that order and retest after correcting it. Waiting cannot repair a wrong mapping or an uncollected value.
How do you test unavailable appointment context separately?
Keep the source data populated and vary the entry path. This isolates a different question: can the send action identify the intended appointment in this execution?
Prepare a test contact with a known appointment. Run the workflow through the event intended to carry that appointment, then inspect the available fields and resulting text. Compare that result with a separate contact-only entry path if your setup permits it. Do not treat manually adding a contact as equivalent to reproducing an appointment event.
Record the event, appointment identity, selected field and rendered output for each run. If the populated appointment works through its intended event but not through another path, investigate context before changing the saved appointment data.
Include a test contact with multiple appointments. Your acceptance check should require the intended visit, not merely a nonblank date. If you cannot establish which appointment supplies the value, hold the reminder for review.
Review rule: A populated field is not sufficient evidence of a correct message. Match the content to the intended contact, client account and appointment.
How do you check reusable account values?
Review reusable values in the destination client account before approving a copied workflow. HighLevel places Custom Values under Settings and describes them as reusable information, such as a support address or standard message. Individual customer details belong in record-specific fields. The Custom Values documentation explains that distinction.
For your worksheet, inspect the stored value, the selected token and the rendered wording. Confirm that the business label belongs to this client and that a booking link opens the intended destination.
Do not repair a missing customer name by putting a sample person’s name into a reusable account value. That would confuse the intended ownership of the information. Use a neutral greeting or correct the customer’s record instead.
What should you inspect in the final webhook body?
Inspect the actual outgoing message after field substitution. A template that looks correct in an editor does not prove that the request contains the intended text.
Use the iMessage API overview to orient your integration review, and check the endpoint used by the workflow. In the documented workflow request, the message content belongs in the message property. Do not interchange payload formats from different send paths.
For the field check, compare the expected sentence with that property’s rendered value. Look for blank spans, unresolved tokens, missing dates, incorrect business names and broken links. If an intermediate service builds the request, inspect its output too. Record only the data needed for the test and keep authorization values out of shared screenshots.
Begin with the documented dry run, then perform a controlled send to your test contact. Validation alone does not show what appeared on the recipient’s phone. Compare the received text with the inspected request and check the same contact’s conversation record. The Beam workflow guide describes this validation and send sequence. Use the agency GoHighLevel texting guide to plan the wider client rollout.
What should send when required fields are absent?
Select a complete approved message before the sending action. Do not leave the renderer to improvise a replacement.
HighLevel’s merge-field overview discusses an email-builder conditional-content workaround. That is not evidence that email fallback syntax works in SMS or Beam webhooks. Verify the exact action instead.
Ask the client to approve a generic message that makes no unverified appointment claim. For example, this hypothetical copy uses a static business identity:
Hello, this is Example Service Team. Please reply if you need help with scheduling.
Replace the sample identity before approval. Use this branch only when the message remains appropriate, texting is permitted and someone can handle the reply. Missing recipient identity or unresolved sending restrictions should hold the send for review.
Implement a condition before sending: verified required details select the personalized version; absent details select the approved generic version or a hold. If the workflow cannot check the needed context reliably, have the integration enforce that requirement before dispatch.
Keep the worksheet and approved wording with the client’s workflow notes. When form mapping, calendar setup and follow-up ownership need coordinated work, MetaTech’s managed services provides relevant implementation support.
What questions do agencies ask about blank merge fields?
Why is a first name blank even though the contact exists?
Inspect the exact first-name field on the contact used by the workflow. A record can exist without that field being populated. Check the selected merge field and compare the saved data with the rendered message.
Does an appointment on the contact guarantee appointment fields will work?
Treat appointment availability as something to verify in that workflow execution. Test through the intended appointment event and inspect which appointment supplies the message details. A visible calendar entry alone is not enough evidence.
Can I copy email fallback syntax into a text webhook?
Do not assume email fallback syntax works in SMS or a webhook body. Use a tested condition that selects a complete message, or hold the send when required information cannot be verified.
What should an agency keep after fixing blank fields?
Keep a field map, the expected message, the inspected request body and the received test text. Record which checks passed and who owns any unresolved data or workflow issue.