Genesys Cloud - Main

Dear Soumik, we do have the case with Genesys opened in regards of similar sounding issues with incorrect statuses on agents. 

Even if agents change their status to Available it is not being recognized by Genesys Cloud and they are still being seen as On Queue which is causing issues with delivering the interaction even to agents not being ready.

As you mentioned it is quite sporadic issue but happening more often for some specific sites and usually after certain period of inactivity. 

We do have as well ZScaler proxies with SSL inspection in place, at physical locations and also for our client PCs as client app.

ZScaler did not come to the radar as suspected root cause until I have read your post and we will validate this as option... 

Yes I did open cases. As usual, they demanded Console and Network logs to triage. The first difficulty we faced was that which agent do we trace, as the agents were getting this phenomenon randomly. Using the Automatic Log Collection facility of Genesys Cloud, we traced a couple of agents at random, which meant we didn't get Network Logs. The analysis of the logs seemed to indicate that the client-side was losing Internet connection when this phenomenon happened. As the agents mostly faced this issue after locking their Windows computers and going for long breaks (30 minutes or so as per their WFM schedule), we suspected it might be something to do with power management policy on the agent computers, e.g. closing down Internet connection when the system was idle for long periods of time. Genesys also suggested to check if the browser policies were somehow set for memory management and didn't whitelist Genesys Cloud Web UI to always remain in memory when open. The customer's IT team are considering a three-fold set of actions.

• For the time-being, agents have been advised that whenever they come back from long breaks, especially as they are required to lock their computers, they should refresh the browser as soon as they unlock their computers. This reduces the impact significantly.
• Customer uses Chrome as their standard browser, so Chrome browser settings to implement memory management and whitelist apps.<Genesys Cloud base URL> is being tried out for some agents. We haven't been told if it has produced good results, but so far they aren't raising Incidents.
• Customer is also checking on the IT policies for power management on both the computer HDD as well as the NIC card, so that during long periods of inactivity they shouldn't be rendered inactive. However, since these form part of cybersecurity controls, it is a long-winded process for them to get approvals to do a proof-of-concept as well. Once again, I haven't heard from the client on anything negative.

Off late though, we have started seeing random occurrences of a significant population of agents in multiple locations simultaneously be rendered unable to change their Primary Status. While a refresh solves the issue temporarily, sometimes a few agents actually get login failures and have to retry a couple of times to login to Genesys Cloud again. At present, the impact is sufficiently less that they are not screaming about it, but Genesys doesn't seem to have any answers.

Dear Soumik, we do have the case with Genesys opened in regards of similar sounding issues with incorrect statuses on agents. 

Even if agents change their status to Available it is not being recognized by Genesys Cloud and they are still being seen as On Queue which is causing issues with delivering the interaction even to agents not being ready.

As you mentioned it is quite sporadic issue but happening more often for some specific sites and usually after certain period of inactivity. 

We do have as well ZScaler proxies with SSL inspection in place, at physical locations and also for our client PCs as client app.

ZScaler did not come to the radar as suspected root cause until I have read your post and we will validate this as option... 

Hi Soumik

We maybe experience the same issue with some of our users so will check some of those bullet points above.

Users will be working fine receiving inbound interactions, then their agent state greys out and taken off-queue.

Unsure their level of inactivity in the build up. 

Are you experiencing this issue on both Chrome and Edge?

What's the latest from Genesys?

Yes I did open cases. As usual, they demanded Console and Network logs to triage. The first difficulty we faced was that which agent do we trace, as the agents were getting this phenomenon randomly. Using the Automatic Log Collection facility of Genesys Cloud, we traced a couple of agents at random, which meant we didn't get Network Logs. The analysis of the logs seemed to indicate that the client-side was losing Internet connection when this phenomenon happened. As the agents mostly faced this issue after locking their Windows computers and going for long breaks (30 minutes or so as per their WFM schedule), we suspected it might be something to do with power management policy on the agent computers, e.g. closing down Internet connection when the system was idle for long periods of time. Genesys also suggested to check if the browser policies were somehow set for memory management and didn't whitelist Genesys Cloud Web UI to always remain in memory when open. The customer's IT team are considering a three-fold set of actions.

• For the time-being, agents have been advised that whenever they come back from long breaks, especially as they are required to lock their computers, they should refresh the browser as soon as they unlock their computers. This reduces the impact significantly.
• Customer uses Chrome as their standard browser, so Chrome browser settings to implement memory management and whitelist apps.<Genesys Cloud base URL> is being tried out for some agents. We haven't been told if it has produced good results, but so far they aren't raising Incidents.
• Customer is also checking on the IT policies for power management on both the computer HDD as well as the NIC card, so that during long periods of inactivity they shouldn't be rendered inactive. However, since these form part of cybersecurity controls, it is a long-winded process for them to get approvals to do a proof-of-concept as well. Once again, I haven't heard from the client on anything negative.

Off late though, we have started seeing random occurrences of a significant population of agents in multiple locations simultaneously be rendered unable to change their Primary Status. While a refresh solves the issue temporarily, sometimes a few agents actually get login failures and have to retry a couple of times to login to Genesys Cloud again. At present, the impact is sufficiently less that they are not screaming about it, but Genesys doesn't seem to have any answers.

Dear Soumik, we do have the case with Genesys opened in regards of similar sounding issues with incorrect statuses on agents. 

Even if agents change their status to Available it is not being recognized by Genesys Cloud and they are still being seen as On Queue which is causing issues with delivering the interaction even to agents not being ready.

As you mentioned it is quite sporadic issue but happening more often for some specific sites and usually after certain period of inactivity. 

We do have as well ZScaler proxies with SSL inspection in place, at physical locations and also for our client PCs as client app.

ZScaler did not come to the radar as suspected root cause until I have read your post and we will validate this as option... 

Hi Soumik,

Did you find the root cause for this and a solution? It started happening to our agents as well and we cannot pinpoint where the issue is coming from.

Thank you!

Hi Soumik,

Did you find the root cause for this and a solution? It started happening to our agents as well and we cannot pinpoint where the issue is coming from.

Thank you!