Set Variable step drops +61 prefix on Sydney edge IVR flow

Architect & Flows
1

Pushing a fresh IVR flow through the Sydney edge on mypurecloud.com.au and the Set Variable step keeps bombing out when processing +61 mobile prefixes. The flow version sits at 2.4.1 and we’re running the latest Genesys Cloud Architect update from last Tuesday. Routing inbound calls from Victoria hits the Data Action step first, then immediately drops into a 400 Bad Request with the error code ERR_FLOW_STEP_INVALID_FORMAT. The payload looks fine locally, but once it crosses into the Australian telephony stack, the number normalization step strips the leading zero and mangles the E.164 format. ACMA compliance rules require that exact prefix structure for recording triggers, so the downstream compliance block never fires. Console logs show the variable gets set to null before the routing logic even evaluates. Mic stays hot on the test line while the flow just hangs on the timeout step.

Latency on the Sydney edge is sitting around 450ms right now, which usually just makes the music on hold sound choppy, but here it’s actually timing out the HTTP request before the response headers come back. Tried swapping the Data Action to a pure JSON mapper and the result stays the same. Doesn’t matter how many times the cache refreshes. The request body looks like this when it hits the step:

{
 "from": "+61412345678",
 "compliance_flag": "acma_recording=true",
 "region": "ap-southeast-2"
}

Switched the flow to a basic queue and it processes the +61 numbers without breaking a sweat. The Set Variable step just refuses to hold the string once the compliance tag attaches. Doing jack all to fix the normalization engine since it treats the Australian prefix like an invalid character set.

2

The ERR_FLOW_STEP_INVALID_FORMAT error usually means the JSON schema validation is failing on the data type, not the string content itself. The Architect engine expects a specific structure for dynamic data actions.

Check your payload in the Set Variable step. You need to ensure the value is wrapped correctly if you’re passing it from a previous transcription or header capture.

{
 "name": "caller_phone",
 "value": "{{trigger.call.callFrom}}"
}

If you are hardcoding for testing, make sure the quotes are standard ASCII. The Sydney edge sometimes chokes on smart quotes copied from docs.

Also, verify the variable type is set to String. If it’s set to Number, the + character will cause an immediate parse failure. This isn’t a timezone issue since you’re in America/Sao_Paulo, just a schema mismatch.

Try adding a Validation step before the Set Variable to log the raw input. That usually reveals hidden characters.