Hi George,
Tiago fell in to the same trap that I did a while back. Numbers plan classification is ignored in architect flow 'transfer to number'. So the number in the flow will be correct, say for example a 7 prefix to denote going out to a different trunk. If the number plan is 'above' National, it will regex strip the 7, in my case, normalise with +44 and classify to '7prefix' which is used on a different outbound route & trunk (for caller Id purposes in my case), unfortunately it will fall in to 'National' number plan and take that route+classification instead, completely ignoring the first classification , but using its normalisation!
If I put the number plan below national, it does not rework the number, keeps the 7 prefix and fails due to incorrect number over the default trunk.
Simulate call and dialing from the agent desktop both work as expected, going over the new trunk. There is no use case that can exist to justify these results, hence why I still class it as a bug. Unfortunately I could not convince the dev's, and my idea submission is not likely to gain enough votes, even though you can see by this chain that most people 'think' that this requirement is a fairly obvious one, just not many people actually do it in reality.
Case #0003614695
As advised, this issue has been already consulted with an SME and have already dug deep with the edge logs and found out that there was already a closed Dev case regarding this. Dev team stated that it's working by design, and it will not be changed.
------------------------------
Kevin Young
TTEC Digital, LLC
kevin.young@ttecdigital.com
------------------------------
Original Message:
Sent: 02-08-2026 21:12
From: George Ganahl
Subject: Transfer to an external number not going via the correct trunk even that rules are set to do so
Have you looked at the Execution Data in the Architect flow doing the transfer to see exactly what number and format is being used for the outbound call on the transfer?
------------------------------
George Ganahl GCCX-AI, GCP, GCD
Technical Adoption Champion
Genesys
Original Message:
Sent: 02-06-2026 09:08
From: Tiago Silva
Subject: Transfer to an external number not going via the correct trunk even that rules are set to do so
hi Kevin,
it indeed makes sense, but I am wondering if this is some sort of config/bug as the rules seem to be working when we simulate, but not when we route calls from Architect?
I thought the rules should apply to any call from the site, so we could select a different trunk to send the calls out from? (or transfer them). I'll review the idea and vote, but as you said there was not traction on it... hmmm
A Support case maybe is a better idea?
Cheers
Tiago
------------------------------
Tiago Silva
Senior Sales Engineer
Original Message:
Sent: 02-06-2026 04:47
From: Kevin Young
Subject: Transfer to an external number not going via the correct trunk even that rules are set to do so
Hi Tiago,
You are falling in to the same 'bug' that I found, that Architect number transfer does not respect the same rules as agent/simulated call on the number plans.
I had to submit an idea, which has gained zero traction, so must be a very low used solution design.
https://genesyscloud.ideas.aha.io/ideas/SSAAOB-I-231
------------------------------
Kevin Young
TTEC Digital, LLC
kevin.young@ttecdigital.com
Original Message:
Sent: 02-05-2026 11:42
From: Tiago Silva
Subject: Transfer to an external number not going via the correct trunk even that rules are set to do so
Hi all,
need some help please. In a nutshell:
- Call lands in Genesys using a Genesys Voice Trunk
- Routing transfers to "external number" that i've collected from a Data Table (33123456789@rtt.voip.parloa.com) via an Architect flow (listened to it and is doing the right thing)
- There is a site number plan set :^([^@\:]+@)(rtt\.voip\.parloa\.com)$
- there is an Outbound route set with the new trunk configured (and also the Main trunk as default)
- Simulated call as per the format shared, it works as it seems to target the new trunk
- But the Inbound call via my mobile don't, listening to it the format seems exactly as the above (second point)
- Call continues to be routed via "default route" (if i change the respective trunk there, the new one works so it does not seem that Trunk is the issue)
How can I enforce the correct trunk to be used?
any help please?
Thank you
#Telephony
#BYOC
#ExternalTrunk
------------------------------
Tiago Silva
Senior Sales Engineer
------------------------------