POST /api/v2/outbound/campaigns/syd-pred-0421/predictive throws {"code":"bad_request","message":"Invalid national number format for ACMA compliance check"}. Platform v2024.4.2 on mypurecloud.com.au won’t keep the +61 prefix right before the predictive router hands off to the media server. It’s dropping the digits, throughput flatlines during the ACMA consent prompt, and the Architect flow logs just show NATIONAL_FORMAT_INVALID before…
This smells like a data type mismatch in the contact list ingestion rather than a routing bug. The predictive engine expects the phone number to be stored as a string with the full E.164 prefix, but sometimes CSV imports strip the + if the column is auto-detected as numeric.
Check your POST /api/v2/outbound/contacts payload. You need to ensure the phoneNumber field is explicitly typed as a string and retains the country code. If you’re using the SDK, force the conversion before sending:
const contact = new platformClient.OutboundContact();
contact.phoneNumber = String(rawNumber).startsWith('+') ? rawNumber : '+61' + rawNumber;
// Ensure no leading/trailing whitespace
contact.phoneNumber = contact.phoneNumber.trim();
Also verify the Campaign settings. Under Predictive > Compliance, make sure ACMA Consent is enabled and the Media Server region matches the edge (Sydney). If the media server is in a different region, the prefix handling might fail during the handoff.
Double check the Contact List schema too. Sometimes legacy lists have a nationalFormat flag that overrides the international prefix.
Cause: The predictive dialer isn’t stripping the prefix. The ACMA compliance check in the Architect flow is failing because the NATIONAL_FORMAT_INVALID error usually means the downstream media server expects a specific national format (04xx) but receives the international format (+61) when the acmaConsent setting is true. The platform validates the number against Australian telecom standards before initiating the call. If the number format doesn’t match the expected national pattern for the region, it rejects it to prevent illegal robocalls. This is a data hygiene issue, not a routing bug. The +61 prefix is valid E.164, but the ACMA prompt logic might require normalization to local format first.
Solution: You need to normalize the phone number in the Architect flow before the predictive dialer action. Use a Data Action to strip the +61 and prepend 0. Here is the configuration:
{
"name": "NormalizeAU",
"type": "dataAction",
"data": {
"phoneNumber": "{{contact.phoneNumber}}"
},
"expression": "if(startsWith(phoneNumber, '+61'), concat('0', substring(phoneNumber, 3)), phoneNumber)"
}
Pass this normalized value to the phoneNumber field in the Predictive Dialer action. Ensure the contact list ingestion keeps the raw +61 for logging, but the flow transforms it for the ACMA check. Also, verify your campaign settings in POST /api/v2/outbound/campaigns have acmaConsent: true and acmaConsentType: "voice". If you skip the normalization, the media server rejects the call before the agent ever speaks. This fixes the flatline throughput.