- 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
Becky_PowellGenesys Employee
Oct '21
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?
Yes, this feature governs the behavior of access tokens generally, regardless of the user who issued them or the clients they were issued to
Thanks. Is any work being done to separate the requested user/client for this? Obviously the feature is great for logging out users but breaks other things like SCIM.
Hi Vaun, not yet. Please vote for this idea if you are interested in this functionality: https://genesyscloud.ideas.aha.io/ideas/OP-I-1185. Thank you!
1 Like
What is the status of this? It's one of the main issues we have with our security team and I have implemented this on our pre production but would like to have some better control on this and as mentioned by VaunMcCarthy the accounts that should be excluded. Being a Bank has certain security requirements that we can't meet with Genesys Cloud.
I want to encourage everyone using Genesys Cloud to go and vote for ideas when they apply to you or your customers needs. It really helps. Also get your local PM to link ideas to the customers the ideas would help.
We are finalizing UI development now and plan to release the UI next month. Thank you!
Hi @Becky_Powell ,
We are using this feature within the Genesys Embeddable Framework which is incorporated within our Airbnb's agent tool . We enabled the inactivity timer & set it to 90 minutes via the API endpoint as described within the documentation and noticed that the agents are not getting auto-logout despite they being inactive.
We did the test by logging in one of our engineers to Genesys Cloud via the embeddable framework within our Airbnb Agent Tools application and left the computer untouched (no activity) for more than 90 minutes and it still keep the agent as active without logging the user out. Can you please investigate and advice why the inactivity timer is not working as expected?
We reached out to Genesys Tech Support and have been re-routed here as this is still in Beta & they do not support it until its being GA. Please do let us know if console logging or any further information which might help to investigate this issue?
Thanks,
Balaji
(Airbnb)
1 Like
Hi Balaji - it's good to hear from you! Are you able to open the Developer Console from whichever page you are working in and watching for any API calls that contain an access token in the Authorization header? This will show you what is extending the life of your access token.
@Becky_Powell - Thanks for taking a look at this. If i understand correctly, the Inactivity Timer / Auto-Logout functionality is not natively supported for embeddable framework implementations unlike the standard GC Client? The recommendation / workaround is to ping the GC Public APIs to mimic the functionality?
@Balaji_Arunachalam if you do not wish for users to be logged out, then yes, our recommendation is to periodically call the GC public APIs to keep the session alive.
Hi! If we would create external app that would call some API in /api/v2/scim domain in regular intervals (less than configured timeout) - would that solve the SCIM issue?
