ÃÛ¶¹ÊÓƵ

Documentation

Dynamic fields from payload arrays fail in AJO push notifications

Last update: Wed Jul 09 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

In ÃÛ¶¹ÊÓƵ Journey Optimizer (AJO), push notifications fail to render dynamic fields from payload arrays—like "callerName"—even though the same data works in Email and SMS. Fields may appear blank or show special characters as hexadecimal codes. To fix this, simplify your expressions, flatten the payload if possible, and ensure UTF-8 encoding is preserved end to end.

Description description

Environment

Product: ÃÛ¶¹ÊÓƵ Journey Optimizer (AJO)
Channels: Push (iOS via APNs, Android via FCM)

Issue/Symptoms

Dynamic personalization fails for array-based fields in push notifications.

Steps to Reproduce

  1. Create a journey in AJO that triggers a push notification.

  2. Pass a payload where the personalization attribute is part of an array, for example:

    code language-none 
    {
  "attribute_list_group": [
    {
      "name": "callerName",
      "value": "Bill Robert"
    }
  ]
}

  3. In the push notification title/body, configure a personalization expression:

    code language-none 
    #each context.journey.events.[ eventId] ._tmobile.decision_detail_group.attribute_list_group as |container|
  {%#if contains(container.name, "callerName")%}
    container.value
  {%/if%}
/each

  4. Send the notification.

Observed: On mobile, the field appears blank or shows hexadecimal codes for special characters. The same expression works correctly in Email and SMS channels.

Cause

  • AJO’s push channel parser is stricter than Email and SMS. It expects flat string values and has limited support for loops, complex expressions, and non-string data types in the title or body.
  • The templating and helper syntax (Handlebars vs. Nunjucks/Liquid) may not be equally supported in push notification fields.
  • Special characters in the payload may be encoded as hexadecimal (e.g., \u2019) during serialization. Push services and some device apps may not decode these sequences and instead display them as-is.
  • Push services like APNs and FCM enforce UTF-8 encoding, reject control characters, and may misrender, drop, or reject messages with malformed or escaped sequences.
  • AJO only supports properly typed strings. If a dynamic expression resolves to an object, malformed string, or array, the push message may silently fail or be truncated.

Resolution resolution

  • Remove all whitespace and newlines from your looping expression. Use a compact version like this:#each context.journey.events.[ eventId] ._tmobile.decision_detail_group.attribute_list_group as |container|{%#if contains(container.name, "callerName")%}container.value{%/if%}/each This resolved the issue for Latin characters in a current customer implementation.
  • If possible, flatten the payload by moving callerName to a top-level field. Then use event.callerName directly in the push template.
  • If flattening isn’t an option, make sure the correct array index is selected and test the personalization preview in AJO to confirm rendering.
  • Ensure UTF-8 encoding is preserved at every stage—from the source system to AJO processing to the push service. Avoid double-encoding or escaping special characters.
  • If special characters still appear as hexadecimal, it’s likely a limitation of the push channel or device rendering. AJO doesn’t currently offer a setting to force decoding of these characters on the device.
recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f