## TL;DR
Wrong macro variables in sent replies mean the macro referenced fields that were empty, wrong-scoped, or renamed, and nobody checked before sending. Validate at apply time: resolve every placeholder against the ticket, flag empties and unknowns before the draft is editable, and keep a registry of allowed variables per macro. A macro that cannot resolve cleanly should warn, not silently send blanks.

## The query

```text
support agent citing wrong macro variables in replies: placeholder validation
```

## Use this when

- Replies go out with blank or wrong macro variables
- Customers receive literal placeholder text
- You are building macro guardrails
- Auditing macro usage quality

## Not for

- Writing the macro response copy
- Macro naming conventions
- Chatbot variable handling
- Ticket field design

## Steps

### 1. Resolve every placeholder at apply time

When the agent applies the macro, resolve all placeholders against the current ticket immediately and show the resolved draft. Resolution at apply time surfaces problems when they are cheapest to fix.

Expected output: drafts show resolved values instantly on apply.

### 2. Flag empties and unknowns before editing

Any placeholder that resolves empty or references an unknown field gets a visible warning in the draft. The agent then fills it in or picks a different macro. Silent blanks are the failure; visible warnings are the fix.

Expected output: unresolved placeholders visibly flagged in every draft.

### 3. Maintain an allowed-variable registry per macro

Each macro declares which variables it uses. A registry lets you audit: which macros use the renamed field, which macros break when a field becomes optional. Review the registry when fields change.

Expected output: a variable registry per macro, reviewed on field changes.

### 4. Test macros against representative tickets

Keep a set of test tickets covering the field variations: empty optionals, different ticket forms, different user types. Apply every macro to the set after any macro or field change. Testing beats hoping.

Expected output: a macro test suite run on every change.

### 5. Track variable-error rate per macro

Count replies sent with unresolved or wrong variables, per macro. A macro with a rising error rate needs its variables fixed or its usage restricted. Retire macros that cannot be made reliable.

Expected output: per-macro error rates tracked, bad macros fixed or retired.

## Template: the checklist

```text
Macro variable validation:
[ ] Placeholders resolved at apply time, shown in the draft
[ ] Empties and unknowns flagged visibly before sending
[ ] Allowed-variable registry maintained per macro
[ ] Test ticket set covering field variations
[ ] Per-macro variable-error rate tracked
```

## Variant phrasings

### macro sent with blank fields

Steps 1 and 2. Resolve at apply, flag the empties.

### wrong placeholder values in macro reply

Steps 2 and 3. Flag unknowns, audit the registry.

### testing zendesk macros before rollout

Step 4 as the QA practice.

## Why it happens

Macros are authored against an imagined ticket with all fields populated, then applied to real tickets where fields are empty, forms differ, and names changed last quarter. The gap between the author's imagined ticket and the agent's real ticket is where wrong variables come from. Validation at apply time closes the gap at the last responsible moment.

## Edge cases

- Conditional ticket fields: a field that exists only in some branches. The macro needs a fallback for the other branches.
- User versus ticket scoping: a user-field variable on a ticket without that user data. Confirm scope per variable.
- API-applied macros: the API context may resolve differently than the agent UI. Test both paths.
- Locale-specific fields: a variable populated in one language but empty in another. Test per locale.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fTu8SqjdVerKI1CCrHPGuw