Genesys Cloud - Main

#ArchitectureandDesign
#PlatformAdministration
#QualityManagement
#SystemAdministration
#Telephony

------------------------------
Shane
------------------------------

Hi Shane,

For Challenge #1, I believe calling via the external trunk is the only way to make sure "internal calls" are recorded as you highlighted, the call needs to go over an external trunk to be recorded, I am not aware of any issues with doing this.

For Challenge #2, You can't prevent the recording, but you could use Access control and call recording segments to restrict who can access the specific segments of the recording.  (or secure Pause as per George)

------------------------------
Sam Jillard
Online Community Manager/Moderator
Genesys - Employees

Original Message:
Sent: 04-30-2025 11:31
From: Shane Jenkins
Subject: Call Recording challenges for Internal calls and Internal transfers

#ArchitectureandDesign
#PlatformAdministration
#QualityManagement
#SystemAdministration
#Telephony

------------------------------
Shane
------------------------------

For Scenario 2, Change the transfer to queue to a transfer to DID (any made up internal one will do) that has an inbound call flow that will secure pause. This way the call flow will be guaranteed to execute, whereas an in queue flow is not, depending on agent availability.

Thanks for the awesome responses so far! Really great information. 

I do have a quick follow-up for Scenario # 1 (Internal calls to a flow not getting recorded). 

We tried setting up a Number Plan w Classification for a specific number. Set the Classification on an Outbound Route to hit an External Trunk.

When we test it doesn't seem to be working and when we Simulate Call, it does show hitting the proper Number Plan and Classification that we created. 

However in Simulate Call, the last two lines (Outbound Route and External Trunk) both show as N/A (Internal Call).

Is there a step we're missing to force this internal DID out an External Trunk? We are BYOC, in case that matters any. It seems like it simply won't allow us to route a number assigned to a flow outward toward an external trunk.

Thanks again,

For Scenario 2, Change the transfer to queue to a transfer to DID (any made up internal one will do) that has an inbound call flow that will secure pause. This way the call flow will be guaranteed to execute, whereas an in queue flow is not, depending on agent availability.

Hi Shane,

As far as I am aware you cannot force a DID to go over the external trunk when it is defined as an internal range, i.e not from your BYOC provider. Even external facing DIDs would still be kept 'internal' afaik. The only way we achieve this is to have DIDs provisioned externally, not defined in GC, then forwarded back to a DID that is defined. Would love to be proven wrong on this, but that's my experience. 

Thanks for the awesome responses so far! Really great information. 

I do have a quick follow-up for Scenario # 1 (Internal calls to a flow not getting recorded). 

We tried setting up a Number Plan w Classification for a specific number. Set the Classification on an Outbound Route to hit an External Trunk.

When we test it doesn't seem to be working and when we Simulate Call, it does show hitting the proper Number Plan and Classification that we created. 

However in Simulate Call, the last two lines (Outbound Route and External Trunk) both show as N/A (Internal Call).

Is there a step we're missing to force this internal DID out an External Trunk? We are BYOC, in case that matters any. It seems like it simply won't allow us to route a number assigned to a flow outward toward an external trunk.

Thanks again,

For Scenario 2, Change the transfer to queue to a transfer to DID (any made up internal one will do) that has an inbound call flow that will secure pause. This way the call flow will be guaranteed to execute, whereas an in queue flow is not, depending on agent availability.

Hi Shane,

As far as I am aware you cannot force a DID to go over the external trunk when it is defined as an internal range, i.e not from your BYOC provider. Even external facing DIDs would still be kept 'internal' afaik. The only way we achieve this is to have DIDs provisioned externally, not defined in GC, then forwarded back to a DID that is defined. Would love to be proven wrong on this, but that's my experience. 

Thanks for the awesome responses so far! Really great information. 

I do have a quick follow-up for Scenario # 1 (Internal calls to a flow not getting recorded). 

We tried setting up a Number Plan w Classification for a specific number. Set the Classification on an Outbound Route to hit an External Trunk.

When we test it doesn't seem to be working and when we Simulate Call, it does show hitting the proper Number Plan and Classification that we created. 

However in Simulate Call, the last two lines (Outbound Route and External Trunk) both show as N/A (Internal Call).

Is there a step we're missing to force this internal DID out an External Trunk? We are BYOC, in case that matters any. It seems like it simply won't allow us to route a number assigned to a flow outward toward an external trunk.

Thanks again,

For Scenario 2, Change the transfer to queue to a transfer to DID (any made up internal one will do) that has an inbound call flow that will secure pause. This way the call flow will be guaranteed to execute, whereas an in queue flow is not, depending on agent availability.

This is correct.  Any number programmed into the DID table will not exit the platform and be treated as an internal call.  The only way is to send a call to an SBC and have it send it back to a number programmed into Genesys.  

Hi Shane,

As far as I am aware you cannot force a DID to go over the external trunk when it is defined as an internal range, i.e not from your BYOC provider. Even external facing DIDs would still be kept 'internal' afaik. The only way we achieve this is to have DIDs provisioned externally, not defined in GC, then forwarded back to a DID that is defined. Would love to be proven wrong on this, but that's my experience. 

Thanks for the awesome responses so far! Really great information. 

I do have a quick follow-up for Scenario # 1 (Internal calls to a flow not getting recorded). 

We tried setting up a Number Plan w Classification for a specific number. Set the Classification on an Outbound Route to hit an External Trunk.

When we test it doesn't seem to be working and when we Simulate Call, it does show hitting the proper Number Plan and Classification that we created. 

However in Simulate Call, the last two lines (Outbound Route and External Trunk) both show as N/A (Internal Call).

Is there a step we're missing to force this internal DID out an External Trunk? We are BYOC, in case that matters any. It seems like it simply won't allow us to route a number assigned to a flow outward toward an external trunk.

Thanks again,

For Scenario 2, Change the transfer to queue to a transfer to DID (any made up internal one will do) that has an inbound call flow that will secure pause. This way the call flow will be guaranteed to execute, whereas an in queue flow is not, depending on agent availability.

The way to get around it is to pre-pend something on the number using the Number plane then strip it back off in the External Trunk>Identity>Called Number settings.

Something like my primitive example below

This is correct.  Any number programmed into the DID table will not exit the platform and be treated as an internal call.  The only way is to send a call to an SBC and have it send it back to a number programmed into Genesys.  

Hi Shane,

As far as I am aware you cannot force a DID to go over the external trunk when it is defined as an internal range, i.e not from your BYOC provider. Even external facing DIDs would still be kept 'internal' afaik. The only way we achieve this is to have DIDs provisioned externally, not defined in GC, then forwarded back to a DID that is defined. Would love to be proven wrong on this, but that's my experience. 

Thanks for the awesome responses so far! Really great information. 

I do have a quick follow-up for Scenario # 1 (Internal calls to a flow not getting recorded). 

We tried setting up a Number Plan w Classification for a specific number. Set the Classification on an Outbound Route to hit an External Trunk.

When we test it doesn't seem to be working and when we Simulate Call, it does show hitting the proper Number Plan and Classification that we created. 

However in Simulate Call, the last two lines (Outbound Route and External Trunk) both show as N/A (Internal Call).

Is there a step we're missing to force this internal DID out an External Trunk? We are BYOC, in case that matters any. It seems like it simply won't allow us to route a number assigned to a flow outward toward an external trunk.

Thanks again,

For Scenario 2, Change the transfer to queue to a transfer to DID (any made up internal one will do) that has an inbound call flow that will secure pause. This way the call flow will be guaranteed to execute, whereas an in queue flow is not, depending on agent availability.

Hi George,

Thanks for this! Followed your example but I'm still facing errors.

When I assign the DID, the simulation doesn't hit the external trunk:

When I remove the DID from any assignment, it would hit the trunk but the call is still not being recorded:

When I tried to log the error from the Architect flow, this is what I got: No answer; sipCode='404'.

Not sure if I'm missing something but this doesn't seem like the right behaviour. I'm curious what other elements you've configured (call routing, Architect flow, etc) and ultimately how you're placing the call to enable the recording. 

Thank you!

The way to get around it is to pre-pend something on the number using the Number plane then strip it back off in the External Trunk>Identity>Called Number settings.

Something like my primitive example below

This is correct.  Any number programmed into the DID table will not exit the platform and be treated as an internal call.  The only way is to send a call to an SBC and have it send it back to a number programmed into Genesys.  

Hi Shane,

As far as I am aware you cannot force a DID to go over the external trunk when it is defined as an internal range, i.e not from your BYOC provider. Even external facing DIDs would still be kept 'internal' afaik. The only way we achieve this is to have DIDs provisioned externally, not defined in GC, then forwarded back to a DID that is defined. Would love to be proven wrong on this, but that's my experience. 

Thanks for the awesome responses so far! Really great information. 

I do have a quick follow-up for Scenario # 1 (Internal calls to a flow not getting recorded). 

We tried setting up a Number Plan w Classification for a specific number. Set the Classification on an Outbound Route to hit an External Trunk.

When we test it doesn't seem to be working and when we Simulate Call, it does show hitting the proper Number Plan and Classification that we created. 

However in Simulate Call, the last two lines (Outbound Route and External Trunk) both show as N/A (Internal Call).

Is there a step we're missing to force this internal DID out an External Trunk? We are BYOC, in case that matters any. It seems like it simply won't allow us to route a number assigned to a flow outward toward an external trunk.

Thanks again,

For Scenario 2, Change the transfer to queue to a transfer to DID (any made up internal one will do) that has an inbound call flow that will secure pause. This way the call flow will be guaranteed to execute, whereas an in queue flow is not, depending on agent availability.

Did you set up the External Trunk address transformation when trying to send the call while it's still configured as a DID for Routing?

Hi George,

Thanks for this! Followed your example but I'm still facing errors.

When I assign the DID, the simulation doesn't hit the external trunk:

When I remove the DID from any assignment, it would hit the trunk but the call is still not being recorded:

When I tried to log the error from the Architect flow, this is what I got: No answer; sipCode='404'.

Not sure if I'm missing something but this doesn't seem like the right behaviour. I'm curious what other elements you've configured (call routing, Architect flow, etc) and ultimately how you're placing the call to enable the recording. 

Thank you!

The way to get around it is to pre-pend something on the number using the Number plane then strip it back off in the External Trunk>Identity>Called Number settings.

Something like my primitive example below

This is correct.  Any number programmed into the DID table will not exit the platform and be treated as an internal call.  The only way is to send a call to an SBC and have it send it back to a number programmed into Genesys.  

Hi Shane,

As far as I am aware you cannot force a DID to go over the external trunk when it is defined as an internal range, i.e not from your BYOC provider. Even external facing DIDs would still be kept 'internal' afaik. The only way we achieve this is to have DIDs provisioned externally, not defined in GC, then forwarded back to a DID that is defined. Would love to be proven wrong on this, but that's my experience. 

Thanks for the awesome responses so far! Really great information. 

I do have a quick follow-up for Scenario # 1 (Internal calls to a flow not getting recorded). 

We tried setting up a Number Plan w Classification for a specific number. Set the Classification on an Outbound Route to hit an External Trunk.

When we test it doesn't seem to be working and when we Simulate Call, it does show hitting the proper Number Plan and Classification that we created. 

However in Simulate Call, the last two lines (Outbound Route and External Trunk) both show as N/A (Internal Call).

Is there a step we're missing to force this internal DID out an External Trunk? We are BYOC, in case that matters any. It seems like it simply won't allow us to route a number assigned to a flow outward toward an external trunk.

Thanks again,

For Scenario 2, Change the transfer to queue to a transfer to DID (any made up internal one will do) that has an inbound call flow that will secure pause. This way the call flow will be guaranteed to execute, whereas an in queue flow is not, depending on agent availability.

Yes

From the simulated calls screenshots I posted above, it looks like the transformation is working.

Did you set up the External Trunk address transformation when trying to send the call while it's still configured as a DID for Routing?

Hi George,

Thanks for this! Followed your example but I'm still facing errors.

When I assign the DID, the simulation doesn't hit the external trunk:

When I remove the DID from any assignment, it would hit the trunk but the call is still not being recorded:

When I tried to log the error from the Architect flow, this is what I got: No answer; sipCode='404'.

Not sure if I'm missing something but this doesn't seem like the right behaviour. I'm curious what other elements you've configured (call routing, Architect flow, etc) and ultimately how you're placing the call to enable the recording. 

Thank you!

The way to get around it is to pre-pend something on the number using the Number plane then strip it back off in the External Trunk>Identity>Called Number settings.

Something like my primitive example below

This is correct.  Any number programmed into the DID table will not exit the platform and be treated as an internal call.  The only way is to send a call to an SBC and have it send it back to a number programmed into Genesys.  

Hi Shane,

As far as I am aware you cannot force a DID to go over the external trunk when it is defined as an internal range, i.e not from your BYOC provider. Even external facing DIDs would still be kept 'internal' afaik. The only way we achieve this is to have DIDs provisioned externally, not defined in GC, then forwarded back to a DID that is defined. Would love to be proven wrong on this, but that's my experience. 

Thanks for the awesome responses so far! Really great information. 

I do have a quick follow-up for Scenario # 1 (Internal calls to a flow not getting recorded). 

We tried setting up a Number Plan w Classification for a specific number. Set the Classification on an Outbound Route to hit an External Trunk.

When we test it doesn't seem to be working and when we Simulate Call, it does show hitting the proper Number Plan and Classification that we created. 

However in Simulate Call, the last two lines (Outbound Route and External Trunk) both show as N/A (Internal Call).

Is there a step we're missing to force this internal DID out an External Trunk? We are BYOC, in case that matters any. It seems like it simply won't allow us to route a number assigned to a flow outward toward an external trunk.

Thanks again,

For Scenario 2, Change the transfer to queue to a transfer to DID (any made up internal one will do) that has an inbound call flow that will secure pause. This way the call flow will be guaranteed to execute, whereas an in queue flow is not, depending on agent availability.

For Scenario 2, Change the transfer to queue to a transfer to DID (any made up internal one will do) that has an inbound call flow that will secure pause. This way the call flow will be guaranteed to execute, whereas an in queue flow is not, depending on agent availability.

My recommendation would be to leverage the upcoming capability of station-side recording to capture recordings for these IT Service Desk calls -- that is in fact one of the targeted use cases we would like to solve through station-side recordings.  "Tromboning" these calls to capture them through external trunks is a workable workaround, but relying on product capabilities tend to be a cleaner approach.

On the issue of excluding recording of personal calls, you should be able to establish a set of QM policies where you only retain calls coming through for the IT Service Desk -- the most typical matching criteria of the QM policy would be towards a queue of the IT Service Desk -- and then also to set another broader/catch-all policy to not retain recordings in general.  Note that station-side recordings captured will honor the retention decision that is made based on how QM policies are resolved, and with such you establish your desired goal of only retaining IT Service Desk call recordings but not direct personal call recordings.

Thanks Daniel! Appreciate the response here.

To be sure I'm following you correctly. We do have our QM policies in place today and they are working as desired for all calls to this IT Service Desk that arrive externally or from non-Genesys Cloud users. (those that traverse the external trunk)

Are you saying that if we enable the Station Side policies for agents supporting the IT Service Desk (once they are released / available to us) then those Station Side recordings can/will honor the same policy settings we have for the IT Service Desk today (those that traverse the external trunk today)? 

Sample scenarios: 

(1) Internal Genesys Cloud user dials the IT Service Desk from his/her Genesys Cloud web based phone. This internal call never hits the external trunk. An agent with station side recording enabled answers this ACD interaction (this call will be recorded as per our overarching IT SD recording policy)?

(2) Internal Genesys Cloud user with station side recording enabled dials an HR POC that we do not have an active policy to record. This direct dial internal call (non-ACD) will not be retained and recorded since it as a non-ACD call? (assuming our recording policy does not retain these specific interactions)

Thanks again for the insight into this. Really do appreciate the information.

Regards,

My recommendation would be to leverage the upcoming capability of station-side recording to capture recordings for these IT Service Desk calls -- that is in fact one of the targeted use cases we would like to solve through station-side recordings.  "Tromboning" these calls to capture them through external trunks is a workable workaround, but relying on product capabilities tend to be a cleaner approach.

On the issue of excluding recording of personal calls, you should be able to establish a set of QM policies where you only retain calls coming through for the IT Service Desk -- the most typical matching criteria of the QM policy would be towards a queue of the IT Service Desk -- and then also to set another broader/catch-all policy to not retain recordings in general.  Note that station-side recordings captured will honor the retention decision that is made based on how QM policies are resolved, and with such you establish your desired goal of only retaining IT Service Desk call recordings but not direct personal call recordings.

Devil is in the details as always, but based on your description, I believe that your QM policies in place today will work the way you wanted it to be when it comes time to enable station-side recording for your IT Service Desk agents.  And since you are able to articulate your call scenarios pretty clearly, I am sure that you will be able to test the heck out of it to verify the theory here.

If you haven't already, even if you aren't part of the beta program for station-side recordings, you can follow the information provided in the beta posting to better assess and prepare for the feature's upcoming availability.

Thanks Daniel! Appreciate the response here.

To be sure I'm following you correctly. We do have our QM policies in place today and they are working as desired for all calls to this IT Service Desk that arrive externally or from non-Genesys Cloud users. (those that traverse the external trunk)

Are you saying that if we enable the Station Side policies for agents supporting the IT Service Desk (once they are released / available to us) then those Station Side recordings can/will honor the same policy settings we have for the IT Service Desk today (those that traverse the external trunk today)? 

Sample scenarios: 

(1) Internal Genesys Cloud user dials the IT Service Desk from his/her Genesys Cloud web based phone. This internal call never hits the external trunk. An agent with station side recording enabled answers this ACD interaction (this call will be recorded as per our overarching IT SD recording policy)?

(2) Internal Genesys Cloud user with station side recording enabled dials an HR POC that we do not have an active policy to record. This direct dial internal call (non-ACD) will not be retained and recorded since it as a non-ACD call? (assuming our recording policy does not retain these specific interactions)

Thanks again for the insight into this. Really do appreciate the information.

Regards,

My recommendation would be to leverage the upcoming capability of station-side recording to capture recordings for these IT Service Desk calls -- that is in fact one of the targeted use cases we would like to solve through station-side recordings.  "Tromboning" these calls to capture them through external trunks is a workable workaround, but relying on product capabilities tend to be a cleaner approach.

On the issue of excluding recording of personal calls, you should be able to establish a set of QM policies where you only retain calls coming through for the IT Service Desk -- the most typical matching criteria of the QM policy would be towards a queue of the IT Service Desk -- and then also to set another broader/catch-all policy to not retain recordings in general.  Note that station-side recordings captured will honor the retention decision that is made based on how QM policies are resolved, and with such you establish your desired goal of only retaining IT Service Desk call recordings but not direct personal call recordings.