Genesys Cloud - Main

Good morning, community!

We noticed a weird quirk of In-Queue Call Flows recently that we are hoping to get some information on. We are aware that the "Set Screen Pop" Architect action is just a glorified "Set Participant Data" action. It sets the "scriptId" attribute in Participant Data as well as any other attributes a Script has listed as "Input Data". 

When used in an In-Queue Flow, because of the way participant data is stored in memory and not written to the call until before the flow terminates, scripts can't actually be updated once they hit the In-Queue Flow, unless you transfer to another queue.

This issue is problematic for teams that transfer to queues belonging to other teams that may use different scripts. For example, if someone in our customer experience department receives a call, that call has the CE script loaded on it. Then, they transfer that call to our corporate switchboard queue, and because we can't update the Screen Pop due to how Participant Data is handled, the CE script tries to load again for switchboard agents and fails due to permission errors.

How can we work around this (without restricting transfer permissions or utilizing hacky workarounds which may affect reporting) to ensure the correct script is set every time in all scenarios?

#Scripter #Architect

#ArchitectureandDesign

------------------------------
Nate Reprogle
------------------------------

Hey Nate,

I believe that the interaction between the flow variable and scripts are working as designed. If you would like suggest a change to how this information is presented, I would recommend that you submit your Idea through the Product Ideas Lab.

To Access the Product Ideas Lab and add your idea:

1. Sign in to the Genesys Knowledge Network.
2. On the Product Ideas Lab section, click Browse and Submit Ideas.
3. From the Product Ideas Lab, click Add a Product Idea.

If anyone in the Community has a workaround, I would love to know other are able to accomplish this with their scripting.

Good morning, community!

We noticed a weird quirk of In-Queue Call Flows recently that we are hoping to get some information on. We are aware that the "Set Screen Pop" Architect action is just a glorified "Set Participant Data" action. It sets the "scriptId" attribute in Participant Data as well as any other attributes a Script has listed as "Input Data". 

When used in an In-Queue Flow, because of the way participant data is stored in memory and not written to the call until before the flow terminates, scripts can't actually be updated once they hit the In-Queue Flow, unless you transfer to another queue.

This issue is problematic for teams that transfer to queues belonging to other teams that may use different scripts. For example, if someone in our customer experience department receives a call, that call has the CE script loaded on it. Then, they transfer that call to our corporate switchboard queue, and because we can't update the Screen Pop due to how Participant Data is handled, the CE script tries to load again for switchboard agents and fails due to permission errors.

How can we work around this (without restricting transfer permissions or utilizing hacky workarounds which may affect reporting) to ensure the correct script is set every time in all scenarios?

#Scripter #Architect

#ArchitectureandDesign

------------------------------
Nate Reprogle
------------------------------

Hey Jason,

To be clear, when you say "The interaction between the flow variable and scripts are working as designed", are you saying that not being able to update the Screen Pop within an In-Queue flow is intentional? Obviously if we transferred the call it would be fine, but if the call were to remain in the flow, updating Screen Pop is impossible?

------------------------------
Nate Reprogle

Original Message:
Sent: 05-27-2025 16:17
From: Jason Kleitz
Subject: Issue utilizing Set Screen Pop in In-Queue Flows due to how Participant Data is written

Hey Nate,

I believe that the interaction between the flow variable and scripts are working as designed. If you would like suggest a change to how this information is presented, I would recommend that you submit your Idea through the Product Ideas Lab.

To Access the Product Ideas Lab and add your idea:

1. Sign in to the Genesys Knowledge Network.
2. On the Product Ideas Lab section, click Browse and Submit Ideas.
3. From the Product Ideas Lab, click Add a Product Idea.

If anyone in the Community has a workaround, I would love to know other are able to accomplish this with their scripting.

------------------------------
Jason Kleitz
Online Community Manager/Moderator

Original Message:
Sent: 05-27-2025 12:15
From: Nate Reprogle
Subject: Issue utilizing Set Screen Pop in In-Queue Flows due to how Participant Data is written

Good morning, community!

We noticed a weird quirk of In-Queue Call Flows recently that we are hoping to get some information on. We are aware that the "Set Screen Pop" Architect action is just a glorified "Set Participant Data" action. It sets the "scriptId" attribute in Participant Data as well as any other attributes a Script has listed as "Input Data". 

When used in an In-Queue Flow, because of the way participant data is stored in memory and not written to the call until before the flow terminates, scripts can't actually be updated once they hit the In-Queue Flow, unless you transfer to another queue.

This issue is problematic for teams that transfer to queues belonging to other teams that may use different scripts. For example, if someone in our customer experience department receives a call, that call has the CE script loaded on it. Then, they transfer that call to our corporate switchboard queue, and because we can't update the Screen Pop due to how Participant Data is handled, the CE script tries to load again for switchboard agents and fails due to permission errors.

How can we work around this (without restricting transfer permissions or utilizing hacky workarounds which may affect reporting) to ensure the correct script is set every time in all scenarios?

#Scripter #Architect

#ArchitectureandDesign

------------------------------
Nate Reprogle
------------------------------

Hi, Jason,

Just checking to be sure...did you already try using a Set Screen Pop action as the very first action in the In Queue flow?

There is always a race condition when setting anything in the In-Queue flow, since it doesn't run if a call goes immediately to an available agent.

You would be best to use a workaround for the transfer instead of just transferring directly to queue. Probably the one where you create a dummy External Contact with the [nameOfQueue]-Transfer or something similar. Associate an internal DID that routes to an Inbound Call Flow that uses the Set Screen Pop the Transfer to ACD to send the call to the queue.

Sorry, but unless you set the screen pop before the Transfer to ACD there's no guarantee anything you set in the In-Queue flow will take effect.

Hey Jason,

To be clear, when you say "The interaction between the flow variable and scripts are working as designed", are you saying that not being able to update the Screen Pop within an In-Queue flow is intentional? Obviously if we transferred the call it would be fine, but if the call were to remain in the flow, updating Screen Pop is impossible?

Hey Nate,

I believe that the interaction between the flow variable and scripts are working as designed. If you would like suggest a change to how this information is presented, I would recommend that you submit your Idea through the Product Ideas Lab.

To Access the Product Ideas Lab and add your idea:

1. Sign in to the Genesys Knowledge Network.
2. On the Product Ideas Lab section, click Browse and Submit Ideas.
3. From the Product Ideas Lab, click Add a Product Idea.

If anyone in the Community has a workaround, I would love to know other are able to accomplish this with their scripting.

Good morning, community!

We noticed a weird quirk of In-Queue Call Flows recently that we are hoping to get some information on. We are aware that the "Set Screen Pop" Architect action is just a glorified "Set Participant Data" action. It sets the "scriptId" attribute in Participant Data as well as any other attributes a Script has listed as "Input Data". 

When used in an In-Queue Flow, because of the way participant data is stored in memory and not written to the call until before the flow terminates, scripts can't actually be updated once they hit the In-Queue Flow, unless you transfer to another queue.

This issue is problematic for teams that transfer to queues belonging to other teams that may use different scripts. For example, if someone in our customer experience department receives a call, that call has the CE script loaded on it. Then, they transfer that call to our corporate switchboard queue, and because we can't update the Screen Pop due to how Participant Data is handled, the CE script tries to load again for switchboard agents and fails due to permission errors.

How can we work around this (without restricting transfer permissions or utilizing hacky workarounds which may affect reporting) to ensure the correct script is set every time in all scenarios?

#Scripter #Architect

#ArchitectureandDesign

------------------------------
Nate Reprogle
------------------------------

Hey George, it's been a while! Good to talk to you again.

From our testing, it appears Scripter uses the participant data written to the call and cannot access the data stored in-memory (Which makes sense if it's in-memory).

Scripter component - handleLocationChange change /scripter/?locale=en-us&user=8f23b952-bd51-4291-a12c-5d70d89fbdc2#interactionId=a1aadb98-4f71-48ef-aa6c-e5f31790a0bc
Scripter component - handleLocationChange change /scripter/?locale=en-us&user=8f23b952-bd51-4291-a12c-5d70d89fbdc2#
scripter-ui--root: Retrieving Interaction:  {
    "detail": "a1aadb98-4f71-48ef-aa6c-e5f31790a0bc"
}

Then, later in the call, we see scripter receives the published script data with the incorrect Script ID:

scripter-ui--root: Received Published Script Data:  {
    "info": "9f6f2db0-2af8-4f1f-867b-f1e0bb8d94f0"
}

It would be nice if the Set Screen Pop action would force a write of participant data, but we at least comprehend the current limitation.

Hi, Jason,

Just checking to be sure...did you already try using a Set Screen Pop action as the very first action in the In Queue flow?

There is always a race condition when setting anything in the In-Queue flow, since it doesn't run if a call goes immediately to an available agent.

You would be best to use a workaround for the transfer instead of just transferring directly to queue. Probably the one where you create a dummy External Contact with the [nameOfQueue]-Transfer or something similar. Associate an internal DID that routes to an Inbound Call Flow that uses the Set Screen Pop the Transfer to ACD to send the call to the queue.

Sorry, but unless you set the screen pop before the Transfer to ACD there's no guarantee anything you set in the In-Queue flow will take effect.

Hey Jason,

To be clear, when you say "The interaction between the flow variable and scripts are working as designed", are you saying that not being able to update the Screen Pop within an In-Queue flow is intentional? Obviously if we transferred the call it would be fine, but if the call were to remain in the flow, updating Screen Pop is impossible?

Hey Nate,

I believe that the interaction between the flow variable and scripts are working as designed. If you would like suggest a change to how this information is presented, I would recommend that you submit your Idea through the Product Ideas Lab.

To Access the Product Ideas Lab and add your idea:

1. Sign in to the Genesys Knowledge Network.
2. On the Product Ideas Lab section, click Browse and Submit Ideas.
3. From the Product Ideas Lab, click Add a Product Idea.

If anyone in the Community has a workaround, I would love to know other are able to accomplish this with their scripting.

Good morning, community!

We noticed a weird quirk of In-Queue Call Flows recently that we are hoping to get some information on. We are aware that the "Set Screen Pop" Architect action is just a glorified "Set Participant Data" action. It sets the "scriptId" attribute in Participant Data as well as any other attributes a Script has listed as "Input Data". 

When used in an In-Queue Flow, because of the way participant data is stored in memory and not written to the call until before the flow terminates, scripts can't actually be updated once they hit the In-Queue Flow, unless you transfer to another queue.

This issue is problematic for teams that transfer to queues belonging to other teams that may use different scripts. For example, if someone in our customer experience department receives a call, that call has the CE script loaded on it. Then, they transfer that call to our corporate switchboard queue, and because we can't update the Screen Pop due to how Participant Data is handled, the CE script tries to load again for switchboard agents and fails due to permission errors.

How can we work around this (without restricting transfer permissions or utilizing hacky workarounds which may affect reporting) to ensure the correct script is set every time in all scenarios?

#Scripter #Architect

#ArchitectureandDesign

------------------------------
Nate Reprogle
------------------------------

Good morning, community!

We noticed a weird quirk of In-Queue Call Flows recently that we are hoping to get some information on. We are aware that the "Set Screen Pop" Architect action is just a glorified "Set Participant Data" action. It sets the "scriptId" attribute in Participant Data as well as any other attributes a Script has listed as "Input Data". 

When used in an In-Queue Flow, because of the way participant data is stored in memory and not written to the call until before the flow terminates, scripts can't actually be updated once they hit the In-Queue Flow, unless you transfer to another queue.

This issue is problematic for teams that transfer to queues belonging to other teams that may use different scripts. For example, if someone in our customer experience department receives a call, that call has the CE script loaded on it. Then, they transfer that call to our corporate switchboard queue, and because we can't update the Screen Pop due to how Participant Data is handled, the CE script tries to load again for switchboard agents and fails due to permission errors.

How can we work around this (without restricting transfer permissions or utilizing hacky workarounds which may affect reporting) to ensure the correct script is set every time in all scenarios?

#Scripter #Architect

#ArchitectureandDesign

------------------------------
Nate Reprogle
------------------------------

Hi Nate, if you hadn't already, you could also look at using the "OUTPUT" variable setting in the script the intial inbound queue uses.  If you set something in that script on a variable that's flagged as OUTPUT, then in theory you can use that same variable as "INPUT" on the second queue without needing to worry about set screen pop within that second queue's in-queue flow.

Good morning, community!

We noticed a weird quirk of In-Queue Call Flows recently that we are hoping to get some information on. We are aware that the "Set Screen Pop" Architect action is just a glorified "Set Participant Data" action. It sets the "scriptId" attribute in Participant Data as well as any other attributes a Script has listed as "Input Data". 

When used in an In-Queue Flow, because of the way participant data is stored in memory and not written to the call until before the flow terminates, scripts can't actually be updated once they hit the In-Queue Flow, unless you transfer to another queue.

This issue is problematic for teams that transfer to queues belonging to other teams that may use different scripts. For example, if someone in our customer experience department receives a call, that call has the CE script loaded on it. Then, they transfer that call to our corporate switchboard queue, and because we can't update the Screen Pop due to how Participant Data is handled, the CE script tries to load again for switchboard agents and fails due to permission errors.

How can we work around this (without restricting transfer permissions or utilizing hacky workarounds which may affect reporting) to ensure the correct script is set every time in all scenarios?

#Scripter #Architect

#ArchitectureandDesign

------------------------------
Nate Reprogle
------------------------------

Good morning, community!

We noticed a weird quirk of In-Queue Call Flows recently that we are hoping to get some information on. We are aware that the "Set Screen Pop" Architect action is just a glorified "Set Participant Data" action. It sets the "scriptId" attribute in Participant Data as well as any other attributes a Script has listed as "Input Data". 

When used in an In-Queue Flow, because of the way participant data is stored in memory and not written to the call until before the flow terminates, scripts can't actually be updated once they hit the In-Queue Flow, unless you transfer to another queue.

This issue is problematic for teams that transfer to queues belonging to other teams that may use different scripts. For example, if someone in our customer experience department receives a call, that call has the CE script loaded on it. Then, they transfer that call to our corporate switchboard queue, and because we can't update the Screen Pop due to how Participant Data is handled, the CE script tries to load again for switchboard agents and fails due to permission errors.

How can we work around this (without restricting transfer permissions or utilizing hacky workarounds which may affect reporting) to ensure the correct script is set every time in all scenarios?

#Scripter #Architect

#ArchitectureandDesign

------------------------------
Nate Reprogle
------------------------------