I need a possibility to find if an agent really answers a call.
So I check the current Process Automation event triggers topics. But what I see is that there is only an event when call is ringing at agent (UserStartEvent). But there is no event when agent really answers the call and is really connected to caller, isn't it?
And I don't find and see such a possibility in an Agent Script, too.
Do you know if there is such a way out of the box without the need to build a customized application?
Background is, that customer has requirement that we have to create a Case in the connected Salesforce system but only when call is really answered by agent and agent is connected to caller and caller don't hang up before.
I understand the use case. Why not tie it to when the agent ends the call and assigns a wrap-up code to the call. Then you know the agent has actually taken the call and interacted with the customer. We have a blueprint that is tied to wrap up code. Wouldn't creating the case at the end of the call be a better solution? Would love to hear your thoughts.
Hello John,
thank you very much for that suggestion. Sounds good.
Unfortunately for our customer the agents primarily are working inside of Salesforce and use only Genesys Cloud plugin there. So they need a Salesforce Case after call is accepted by them in Salesforce because they want to add some notes about the call etc.. So when we only create a Salesforce Case after call is ended this is to late for them. So this was the reason why I asked about that specific event when agent accepts the call.
The v2.analytics.conversation.{id}.metrics topic may work for your use case. If you specifically watch for tAnswered metric events, those would emit when the agent picks up the call. The catch is that this topic is going to emit all metrics for the org, so you'd need an application in the middle that filters this information.
for that topic I need a websocket right? Currently this topic is not possible to listen for Process Automation which can I handle in an Architect workflow only, exactly? But I know what you mean and this is a good hint.
If you're working inside salesforce, using the Genesys Cloud for Salesforce client, why don't you look at the Lightning Messaging Service events, which will tell you when a conversation is connected (as opposed to alerting) to a user? This could conceivably kick off a case creation screen flow that guides the agent through the case creation process, and fill in as much information as possible? A screen flow isn't the only option, as salesforce provides a number of ways to create cases, but using the client events as a starting point would allow you to choose which process makes the most sense once you get the event: Events in Salesforce - Genesys Cloud Resource Center
An on-answer event instead of an-alert would be nice in a few scenarios: updating internal systems with the Who/what/where/etc of which rep answered which call, without having to extract the data via the analytics API OR worry about filtering out alert-only calls.
We'd also love to push this answer data to our external KPI's database and also include some real-time alerts for supervisors that their rep has just picked up a call, so they can jump in and live monitor without having to stare at dashboards.
Is there any chance to add new event topics for the Process Automation into the Cloud? This is a very useful mechanism when you want to react on specific events and you won't add external resources like a own app or event handlng directly on AWS.
If so, you can listen to the state of the conversation in the script and make a decision when the state turns from alerting to connected (if you are, I can give more information about how to do this)
I had a similar idea already. Yes I agree that I can get the current state of conversation by Data Action API call in Agent Script. But what I don't get is the problem, that I need something like a loop to ask again if state still the same. And currently there is not such a loop construct in the Script. What is your idea?
I have a script that has a Page Load custom Action called "Check State Value". It checks to see if the state is connected, and if it isn't connected, then it calls another custom action, called "Delay".
The Delay Custom action delays for a few milliseconds and then executes "Check State Value".. Thus the looping mechanism - I'm able to call a custom action from another custom action.
Does that make sense? It will be as close as it gets without any custom code, in my opinion.
These allow for more programmatic access to both the call logging process (which only happens on a conversation connected event) and a stream of events (including an explicit conversation connected event) that could be leveraged to create the case automatically, and only in the event of an agent connecting.
Another alternative would be the use of an apex trigger within Salesforce to key off the activity record being created (again, this only happens when a conversation is connected), and creating your case that way.