Allow me to get back on a subject that I've addressed here previously but, this time, on a slightly different perspective.
Back in the days when I wrote https://developer.mypurecloud.ie/forum/t/automatic-logoff-on-3d-party-integrations/2943, PureCloud was billing concurrent users based on the max peak of agents "on-queue" for more than 30 minutes. Having a user "stuck" "onqueue" was only harmful because it would not release the phone to the next shift. This is not an issue anymore as supervisors can "kick" users out of their phones now.
Nowadays, the users are considered in the peak just by being online so handling user sessions properly is mandatory because, otherwise, we might end up being overcharged.
We've made some tests and, if one uses the PureCloud web client, whenever you close the browser (even if you forget to log out) your user will end up offline shortly.
However, in our case, the majority of the users do not use PureCloud web client. Instead they use, a custom developed unified front-end that interacts with PureCloud using the platform API (namely the Javascript SDK). The SSO is achieved using SAML Bearer authentication (with ADFS). In this scenario, users that don't logout sometimes end up being online for dozens of days and, therefore, contributing to the peak.
It seems to me that PureCloud should have some kind of mechanism that should prevent a user from being online for days without any activity regardless of how the user was authenticated.
Can someone help us achieving this on our scenario?
The feature to set a user to offline after they have closed the UI is a feature that is strictly tied to the official Genesys UI and is not available to custom apps. You will need to replicate this functionality on your own. You must build a service that monitors the connectivity of your custom app so that service can detect when a user has left the app without logging out. Then the service can take action to set the user to offline.
You can request new features, like the ability to use the built-in feature that sets users to offline for your own app, and share your use case at https://genesyscloud.ideas.aha.io/.
When you replied at my previous post on this subject you stated:
This is a back end service that does this
So, my understanding back then was that Genesys UI was sending some kind of heartbeat, trough an API, and, if the heart beat stopped for that user, his session would be killed.
Would you mind elaborate a bit more on how that built-in feature works so we can understand how to reproduce it? It would also help me understand better what I should be proposing in "Idea Lab".
There's not a specific name for that feature. The gist is that the backend service can tell when our UI app is open in a browser and when it's not. You would need to replicate a feature such as that for your software. How you implement that is entirely up to you and will be based on your architecture.
When you say "Backend service" you mean your UI's BFF? Or the api platform?
I agree you with you when you say that the responsabiliy of detecting when our app is closed it is ours.
However, even if our app cannot understand if the user closes its browser, it doesn't make sense to me that PureCloud platform keeps a user session for days without activity regardless of whoever client dispatched the creation of the given session. I believe that the owner of the sessions should be responsible to expire them for inactivity just like, in our app (and in 99% of all the webapps I work with), we expire our BFF sessions for inactivity (in our case 30m)
I'm being intentionally elusive about describing this. It's part of the inner workings of Genesys Cloud that are not meant for public consumption, so I can't provide much detail about how those internal/non-public processes work.
That's not what's happening. A user's presence and routing status have exactly zero relationship with a user's web sessions. A user will remain in any presence indefinitely unless something explicitly decides to change it. Think of presence as a persistent indicator of the last known value set by an app instead of a live representation of the user. It may seem like a pedantic distinction, and under normal circumstances when using our UI it effectively is. But from a technical perspective, understanding that pedantic difference explains why a user's presence doesn't appear to be tied to your app's lifecycle, because it's not. The process that sets a user to offline after they've closed their browser is based on the back end not seeing activity from our UI; it's not based on API requests, the validity of an auth token, or any sort of session. This is why you need your own service to detect when your UI is no longer open so it can set the user's presence to offline; this process is what is happening when using the Genesys UI.
Although I understand the "pedantic difference" and how, when using Genesys UI, this is somehow transparent, when we get charged by this presence value this becomes less and less pedantic. I don't think it's fair from the service providing point of view. This is something, unfortunetely, no one warns you about when you are integrating PureCloud like we did.
Are there any other partners with integration scenarios like ours that you know of? Is there any other channel more "product wise" were we can expose this concern ?
Appreciate your time, Tim. You've been very helpful.