The country information you see in Interaction Details is typically derived from the ANI and/or carrier-provided enrichment and appears as part of post-processing in Analytics. In Architect, real-time routing decisions usually rely on the ANI itself (in E.164 format), not on an explicit "country" attribute provided as a native field.
To make this approach more robust and standardized, instead of manually parsing the number, you can convert the ANI to a Phone Number data type and extract the country code directly using:
Example (conceptual):
From there, rather than building multiple conditional branches (switch/if) in the flow, a cleaner and more scalable pattern is to use a Data Table to map the dialingCode (or a more specific prefix, if needed) to the target queue. This keeps the Architect flow simpler and centralizes routing logic in the data table, making it easier to maintain and extend for global routing scenarios.
------------------------------
Fernando Sotto dos Santos
Consultor Grupo Casas Bahia
------------------------------
Original Message:
Sent: 01-21-2026 09:38
From: Christian Rosenberger
Subject: Location Based Routing recomendations
Couldn't you access directly in Architect the country the caller is coming from? We implemented something also with Mobile/Wired customers calling in. You could also see this in the Interaction Details list.
------------------------------
Christian Rosenberger
System Architekt Customer Interaction Art
Original Message:
Sent: 01-21-2026 09:32
From: Fernando Sotto dos Santos
Subject: Location Based Routing recomendations
Olá @Joaquin Garcia Fink, Greetings from Brazil!
I've implemented a similar solution using the caller's ANI, leveraging the country code plus a geographic prefix extracted from the E.164 number format.
In Brazil, this is straightforward because we can use DDI + DDD as a key to consult a data table. In Architect, the flow extracts these digits from the ANI and performs a lookup in a Data Table, where each DDI+DDD combination is mapped to a target queue.
For a global implementation, the same pattern applies, but instead of relying on a fixed "DDD" structure, the data table is designed to work with variable-length prefixes (for example, +1 212, +44 20, +49 30, +55 11). The flow matches the ANI against these prefixes and resolves the appropriate queue dynamically.
Once the queue name (or ID) is returned from the table, you can apply any additional routing logic required (business hours, skills, priorities, etc.).
This approach avoids requiring the caller to manually provide location information (such as ZIP or postal codes), relies only on native Architect capabilities, and scales well from a single-country deployment to a multi-country/global routing model.
------------------------------
Fernando Sotto dos Santos
Consultor Grupo Casas Bahia
Original Message:
Sent: 01-21-2026 00:00
From: Joaquin Garcia Fink
Subject: Location Based Routing recomendations
One of my customers needs to configure call routing based on customer location.
At some point there seem to be a service available through AppFoundry called Location Smart however doesnt seem to be available anymore.
Wondering if anyone has implemented some similar solution that does not requiere the caller to enter location data (e.g. zipcode)
Thanks!
#Uncategorized
------------------------------
Joaquin Garcia Fink
Senior Customer Success Manager
Genesys - Employees
------------------------------