## TL;DR
A macro placeholder renders blank when the field it references is empty, inaccessible, or out of scope for that ticket. Do not trust the placeholder alone: wrap critical fields with a default ("there" instead of a blank name), verify the field is populated on the ticket forms where the macro is used, and test the macro against tickets with empty optionals. Blank output is a data problem wearing a template problem's clothes.

## The query

```text
zendesk macro placeholder renders blank: {{ticket.requester.name}}
```

## Use this when

- Macro replies send with blank names or fields
- Placeholders render empty on some tickets but not others
- You are QAing macros before rollout
- Auditing macro output quality

## Not for

- Writing the macro response text
- Macro folder permissions
- General Liquid templating
- Requester profile design

## Steps

### 1. Reproduce with the exact ticket shape that fails

Apply the macro to a ticket matching the failing case: same form, same requester type, same empty fields. Placeholders that work on full tickets and blank on sparse ones point at missing data, not broken syntax.

Expected output: the failing ticket shape identified.

### 2. Check the field exists and is populated on that ticket

Verify the requester actually has a name set, and that the ticket form exposes it. System-generated or API-created requesters often lack names; social-channel tickets may too. Empty in, blank out.

Expected output: field availability confirmed per ticket shape.

### 3. Add defaults for every customer-visible placeholder

Give each placeholder a fallback so it can never render blank in a sent reply: a generic greeting instead of an empty name, "your request" instead of an empty subject. Defaults are the last line of defense and should always be present.

Expected output: no placeholder able to render blank in output.

### 4. Restrict the macro to ticket forms where fields exist

If the macro needs fields that only some forms have, limit its availability to those forms. A macro applied where its data cannot exist will always misfire; availability scoping prevents the misfire.

Expected output: macros scoped to compatible ticket forms.

### 5. Preview the macro on empty-field test tickets

Keep test tickets with blank names, missing companies, and empty optionals. Preview every macro against them before publishing changes. The preview catches blanks that full test data hides.

Expected output: a blank-field preview suite run on every macro change.

## Template: the checklist

```text
Macro placeholder blanks:
[ ] Failing ticket shape reproduced
[ ] Field populated and exposed on that shape
[ ] Defaults on every customer-visible placeholder
[ ] Macro scoped to forms where its fields exist
[ ] Blank-field test tickets previewed before publish
```

## Variant phrasings

### macro placeholder empty zendesk

Steps 1 and 2. Reproduce, check the data.

### ticket requester name blank in macro

Steps 2 and 3. Missing name plus a default fallback.

### macro renders blank fields

Steps 3 through 5. Defaults, scoping, preview suite.

## Why it happens

Macro authors build against rich test tickets where every field is filled, then agents apply them to real tickets where requesters are sparse, forms differ, and integrations create users without names. The placeholder is honest: it renders exactly what the field contains, which is nothing. The fix is to design for empty, not for full.

## Edge cases

- End-user versus agent-applied: placeholders resolve against the ticket's requester, not the applying agent. Confirm whose data each placeholder reads.
- Nested placeholders: a default containing another placeholder can blank recursively. Keep defaults literal.
- Locale-specific name fields: some requesters have names only in certain scripts or fields. Test across your user base.
- API-applied macros: resolution context can differ from the UI. Preview through the same path agents use.

## Provenance

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