Running a scheduled Data Action to pull evaluation scores through /api/v2/quality/evaluations?limit=100 on mypurecloud.com.au and the Sydney edge keeps mashing the caller ID formatting. ACMA recording retention reports require the full +61 prefix, but the export JSON truncates it to 2xxxxxx. The Architect flow version sits at 3.1.2 and the GC instance is on the latest quarterly patch. Console throws a 422 Unprocessable Entity with {“error”: “VALIDATION_FAILED”, “code”: 422, “message”: “Caller ID format mismatch on Sydney edge”}. Latency to the Berlin scheduling dashboard is doing jack all to help. Takes about 14 seconds just to spin up the WFM calendar sync. Switching the evaluation criteria to use the internal interaction ID works fine. That doesn’t sit right with compliance though. Forced the number format in the Set Variable step before the API call. Still drops the country code. The same payload against the US East endpoint returns the +61 intact. Definitely an edge-specific routing quirk. Architect logs show the data action completes with a 200, but the downstream webhook payload arrives stripped. WFM timestamp alignment is also throwing off evaluation dates by exactly 9 hours. Backend seems to be mashing UTC and AEST together somewhere. Need the raw numbers to match the telco porting records from the ACMA database. Running the export again tonight to see if the Sydney edge rewrites E.164 strings during quality pulls. The evaluation form version is locked at 4.2.0 and uses standard rating scales. Nothing custom in the JSON schema that would trigger a regex strip.
Have you checked if the issue is actually in how the Data Action is formatting the phone number before it hits the export, rather than the API stripping it? The Quality API itself usually preserves the full E.164 format, but if you’re pulling this into a CSV or JSON file via a Data Action, the default string handling can sometimes drop leading plus signs if it interprets them as operators or if the column type is set to integer instead of text.
I’ve seen this happen a few times with Sydney edge exports where the local formatting rules try to be “helpful” and normalize numbers. You might want to explicitly force the phone number field to be treated as a string in your Data Action configuration. If you’re using a SQL-like query or a custom script step, make sure you’re wrapping it or casting it properly.
Try adding a simple replace function in your Data Action’s field mapping to ensure the plus sign is preserved. Something like this in the expression builder for the phone field:
replace({evaluation.contact.phoneNumber}, "+", "%2B")
Wait, that’s for URL encoding. For the actual data export, you probably just need to ensure the field isn’t being parsed as a number. If you’re using the export action, check the format options. There’s often a setting for preserveLeadingZeros or similar. But if you can’t find that, the safest bet is to prepend a static character and strip it later, or use the concat function to force it into a string context.
concat("", {evaluation.contact.phoneNumber})
This forces the value to be treated as a text string, which should prevent the system from trying to normalize or truncate the +61 prefix. It’s a bit of a workaround, but it’s worked for me when the native export settings were being stubborn. Also, double-check that the limit=100 isn’t causing pagination issues that might be dropping headers or metadata, though that usually results in a different error code. The 422 suggests validation failed on the input, so it might be the query parameters themselves. Are you filtering by a specific division or date range that might be conflicting with the edge settings?