So the analytical/real-time updates does then not count as the agent being active? We will start to test this soon - but have some other priorities to deal with first 
Hi Linda, the best way to tell if API requests are happening behind the scenes is to open your browser's network inspector. Any API requests that you see - whether generated by the user or the system - will count as activity for the user.
Hi Becky,
15 minutes seems quite short, we have Leaders and Supervisor who use GCloud mainly for monitoring agents, these senior users would be logged into Genesys but need to stay idle for a longer period than agents.
- Can the logout time be extended to 60 minutes?
- As we are using SSO, is logging back in a simple refresh of the browser or will the user need to relaunch GCloud?
- Is there any future scope in being able to enable the feature for specific users rather than a org wide approach?
Hi there,
- I am working with my development team to see if we can extend the logout interval during the beta phase. I will answer here in the forum.
- The user is displayed a dialogue instructing them to relaunch Genesys Cloud:
- Please raise this idea in our ideas lab so that we may consider it for future development. Thank you!
1 Like
Hi Becky,
I just want to confirm that the functionality will do the following:
- Disconnect user if they are in wrap-up state (to avoid artificial wrap-up and AHT increase)
- If user left an interaction open, logging them out will return interaction to the queue
Reason why we need this functionality is mainly for instances when agent goes to Wrap Up and forgets to disconnect interaction and stays in wrap up until they return again. And another instance is when agent has an interaction open and ends the shift and then we have him as interacting until they return the following day.
Another thing to note is that we cannot start with Beta until the limit of 15min is increased as our agents are having lunch for either 30min or 1h based on the office they are in.
Thanks,
Dejan
Hi there - thanks for posting.
- The timeout feature will not log out a user who is in the midst of After Call Work - even if they are not clicking or typing.
- The timeout feature will not log out a user who has an open voice or email interaction.
Additionally, I have noted that you cannot start with the beta until we increase the timeout duration. Stay tuned - that functionality will be released soon!
Hello! Could you please help me further by checking it? Before enabling it I would like to monitor a session and check in which situation the API is used, however my lack of knowledge won't let me check it on Developer Console. How can I do it, please?
Thank you.
Hi Becky, Feature was enabled but so far none of the logged in account have logged out.
HIPAA is currently disabled on our Org, would this have impact?
HI Dewalt, this feature works independently of the HIPAA toggle. You do not need to enable it in order for the auto-logout feature to work.
If you are not being logged out it is because some background API calls are being fired behind the scenes. Fo instance, if you have any kind of open interaction you will not get logged off.
Please note that we will likely change the logout logic to "listen" for keystrokes/mouse-clicks in the next iteration.
Hi Becky! Sorry, cannot start a new topic so will ask here.
-
How to prevent the logout from inactivity if the user is active but not interacting with the iFrame? We got a recommendation to send API requests with the user's auth token and it will prevent the logout.
-
Multiple tabs. If a user has 2 tabs opened and sending "activity" (API requests from 1) in 1st tab but the 2nd tab is "inactive". Will it logout 2nd tab? will it logout 1st tab? We got a recommendation that activity in 1st tab is enough to keep both tabs logged in.
Hi there!
- Can you clarify please? I'm not sure I understand the scenario where a user would be active but not interacting.
An example would be very helpful. - We determine activity/inactivity at the auth token level, not on a per-tab level. A user who is logged in to one tab would stay logged in to all other tabs in that browser as long as the user is active.
- I don't know how much I can share in this public forum but George Ganahl from Genesys has more context.
Timeout is set to 30 mins and for one agent it was taking longer than 30 mins to resolve an email conversation. Here is the screen where the agent had an active email conversation but still got a logout notice and got logged out eventually
In our case, agents perform the actual work (sending messages to the customers) outside of Genesys Embedded Framework and we want to send a "heartbeat" event to iFrame to prevent the logout because of inactivity
Revised answer: 2022-02-08T05:00:00Z
Access token inactivity timeout affects only the access token that has not been used. Other access tokens issued to the same or other clients have their own inactivity timeout, and are unaffected by one another.
If a user is administratively logged off, then all their access tokens are revoked, their authentication session at our auth server is deleted, and depending on SLO settings, their session with their IDP as well.
Original: (not valid; please ignore)
Ah, thank you for the explanation. In this case the user is operating via two distinct tokens - one for the embedded client and one for Genesys Cloud proper. If the user is timed out of the embedded client, he would simultaneously be logged out of Genesys Cloud. However, if the user is logged out of Genesys Cloud for inactivity, he may still have a valid access token in the embedded client, in which case he remains logged in to the embedded client. So there should be no scenario* in which the user is logged out of the embedded client just because he is inactive in Genesys Cloud proper.
(*The clients' authenticated states are not tightly coupled, but rely on shared session state in the browser, meaning there are failure modes that could cause the authenticated state to get out of sync.)
HI Becky,
Some feedback: 15 min logout is working as expected. Need some clarity if we can set this higher yet, IE 8 hours etc.
Was also thinking, this auto logoff feature could be linked to agent WFM schedule, set X Seconds on end of shift to log out user (manage agent behavior of not logging out) = free up concurrent license quicker.
Edit: https://genesyscloud.ideas.aha.io/ideas/OP-I-299, this idea seems to cover above.
Hi Dewald - yes, the timeout is configurable to up to 8 hours now.
Thanks,
Becky
1 Like
Hi Becky,
Happy New Year, I wanted to follow up on the bellow request:
Also, just to check, log out window was extended to 8h now?
Many thanks,
Dejan
Good day,
Time can be set to a max of 8 hours.
See Becky's reply to you in Oct
Hi there - thanks for posting.
- The timeout feature will not log out a user who is in the midst of After Call Work - even if they are not clicking or typing.
- The timeout feature will not log out a user who has an open voice or email interaction.
Additionally, I have noted that you cannot start with the beta until we increase the timeout duration. Stay tuned - that functionality will be released soon!
What's the status of this feature guys?
Hi Vaun, we are currently building out the UI component for this feature. Until then we remain in beta. Thank you!
Just to clarify Becky, please, if we're using OAuth for SCIM which obviously has a token generated as part of the setup - does this idle timeout impact on that?