You can set Direct Routing DID to any of the numbers - I usually use Work2 or Work3. I usually set the primary as their extension number or a fake DID. When dialing out of the Direct Routing queue, it will pickup whatever number you have assigned for the direct routing integration (don't miss that step!) As for the *86, after you set the primary, you should have that back. If not, setup a DID to a flow with remote access to voicemail.
Sr. Director - Innovation Architects
Original Message:
Sent: 03-24-2026 22:43
From: Dhanalakshmi Vasudevan
Subject: Blocking Caller From Calling Certain DIDs
Hi Robert,
We have implemented direct routing for one of our customers but it came with some limitations i) users ability to access their voicemail mailbox by dialing *86 ii) supervisors ability to monitor calls of their team.
And when we raised these issues with Genesys support, we were told they were the limitation of setting the direct routing DID as the primary phone number in the user profile. And were asked to set a different DID as primary phone number which defeated the purpose of assigning the DID as primary number to advertise it as CLI on Outbound calls.
So we implemented a workaround of assigning the DID with a different country code. And in the external trunk's Identity -> Calling -> Address Transformation, converted the numbers matching the prefix back to the original DID.
Thanks & Regards
Dhana
------------------------------
Dhanalakshmi Vasudevan
Original Message:
Sent: 03-20-2026 09:57
From: Robert Wakefield-Carl
Subject: Blocking Caller From Calling Certain DIDs
The issue with all of the suggestions you have here, is that once you direct that DID to the flow you have no ability to use that DTID for outbound calls. If these people happen to be agents on the system with a GCX license, then direct routing is definitely the better way to go. This allows agents to have the inbound DID and outbound DID but is treated as a call through a call flow. With that call flow you can do things like the table lookup for restriction of calling the DIDs directly.
------------------------------
Robert Wakefield-Carl
ttec Digital
Sr. Director - Innovation Architects
Robert.WC@ttecdigital.com
https://www.ttecDigital.com
https://RobertWC.Blogspot.com
Original Message:
Sent: 03-20-2026 09:14
From: Cesar Padilla
Subject: Blocking Caller From Calling Certain DIDs
hi @Tim Seneca
You can achieve this in Genesys Cloud by forcing those DIDs to enter an inbound call flow, even if they currently ring users directly. This gives you full control to restrict specific ANIs only for those DIDs, without blocking the customer from calling your main numbers - which aligns with what Legal requires.
How to implement it
1. Route the affected DIDs to an Inbound Call Flow
Instead of pointing those DIDs directly to users, assign each to a simple Architect inbound flow.
This is the key step - once the DID enters Architect, you can apply conditional logic before the call continues.
2. Use a Data Table for restricted callers
You already have a data table for fully blocked callers.
Here, create a second table with DIDs that should be "ANI‑restricted".
Example structure:
| Column | Value |
|---|
| DIDNumber | +12025550123 |
| Notes | Exec DID – restricted |
3. Add logic in the flow
At the start of the inbound flow:
Check if the caller ANI exists in the restricted‑caller table.
If yes, check if the CalledAddressOriginal (the DID) exists in your "restricted DIDs" table.
If both match → decide what happens:
- Play a message (e.g., "This number cannot be reached directly"),
- Hang up,
- Or redirect to your main queue or reception.
If no match → transfer normally to the user/number/group.
This achieves selective blocking without violating the requirement to allow the customer to reach your organization through normal channels.
Why this works
As others mentioned, using Architect is the only way to control inbound behavior on a per‑DID basis.
This approach also avoids the need for API disconnect actions (which require user context, as Kevin noted), because the hang up or redirect actions inside Architect do not require any special permissions.
Optional improvement
If you're using BYOC and need to preserve outbound CLI for those users, you can assign a placeholder number to the DID in the flow and rewrite it at the trunk level as Kevin suggested.
Let me know if you want a sample flow outline - happy to share.
------------------------------
Cesar Padilla
INDRA COLOMBIA
Original Message:
Sent: 03-20-2026 02:33
From: Kevin Young
Subject: Blocking Caller From Calling Certain DIDs
Hi Tim,
For these kind of DIDs we normally assign them to a Inbound call flow instead. After data table lookup the flow can then transfer to User/Number/Group or hangup, with more control over fail over scenarios such as forwarding on no answer, voicemail etc..
If using a BYOC and the outbound cli is important to keep, then you can assign a 'fake' number that can be transformed by the trunk on outbound call.
hope that helps,
------------------------------
Kevin Young
TTEC Digital, LLC
kevin.young@ttecdigital.com
Original Message:
Sent: 03-19-2026 15:32
From: Tim Seneca
Subject: Blocking Caller From Calling Certain DIDs
Good Day All,
Is there a way block an incoming phone # from calling a specific DID(s)? I have a caller that keeps calling certain DIDs (including our senior leadership) to bypass the proper methods. I do have a data table in our main call flow setup that blocks certain numbers from calling in all together. Our legal department has advised we cannot not block the customer from calling in completely. Could you please show me how to achieve this if possible?
Thanks,
-Tim
#ArchitectandDesign
#System/PlatformAdministration
#Telephony
------------------------------
Tim Seneca
------------------------------