Message variable catalog

List the variables a SEND_MESSAGE template binding can reference for a journey — the same set the builder offers, and the authority on what resolves for THIS journey (when docs and this catalog disagree, trust the catalog). customer.* and person.* are offered for every trigger type (person.* is read live at send time from the identity the enrollment named — personExternalId, which event triggers always carry — and only falls back to a phone/email lookup, blank on zero or several matches, for contacts enrolled without a CDP person). The trigger-aware part is participant data: event-triggered journeys get the event payload under engagement.workflowState.* and no engagement.context., segment-triggered journeys get segment output columns under engagement.workflowState., and manual/CSV enrollment populates engagement.context.. event.<property> is an alias of engagement.workflowState.<property> (e.g. event.due_date), valid in a binding and inside email Liquid tags ({% if event.amount > 0 %}, {% for i in event.items %}); the catalog returns the engagement.workflowState. spelling. Bind a template placeholder to one of the returned path values (custom person attributes are person.<key>, NOT attributes.<key> — that is the DECISION/CASE condition syntax). A binding may append ONE formatting helper after a pipe: currency:MXN (code required), date or date:long, sum / sum:field, count, fixed:N — e.g. "engagement.nodeOutputs.fetch.body.total | currency:MXN". No chaining. currency/date are localized to the org language; sum/count/fixed are deliberately NOT, so they stay parseable by a DECISION comparison and valid inside a JSON body. Applied to a missing value the helper is skipped entirely, so a gap renders blank rather than "NaN" or "Invalid Date". count is the one to reach for before indexing an array: binding body.buyers.0.account on a plural array picks an arbitrary element, so gate a DECISION on count eq 1 instead of guessing. Pass a journey id or its initiative id.