ciwe | 2023-02-09 22:02:15 UTC | #1
Hello,
summarize: email -> workflow -> queue -> manually transfer to agent directly
Via the following API endpoint I am able to disconnect an alerting email conversation session for that agent: PATCH /api/v2/conversations/emails/{conversationId}/participants/{participantId}/communications/{communicationId}
The only possibility over this API endpoint is to send the state=disconnect. Every other state I want to send is ending in that response: "Communication state can only be set to disconnected".
So after I disconnected an alerting email session from agent participant the email conversation is still active and not disconnected at all but after it I am not able to transfer that conversation to another participant anymore.
I want to use that API endpoint therefor: POST /api/v2/conversations/emails/{conversationId}/participants/{participantId}/replace
The api response is always: "You can only transfer conversations that are in the connected state." So I see no possibility anmore to assign that conversation via API back to a queue for example. Any idea or something what I have missed?
Thank you very much and best regards, Christian.
ciwe | 2023-02-13 23:55:55 UTC | #2
I found out, when email conversation is transferred directly to an agent and agent is not logged in then there is an active alerting state for this agent until the agent will logged in the next time. During that time I cannot made anything else with it over API. I always get some errors there (e.g. participant is not in connected state).
When agent is logged in and email conversations is ringing at agent side but agent don't answer it and ringing run into timeout then agent state is not active anymore. But conversation at all is still active and I can't do anything with it as well over API.
How I am able to do anything with such conversations without the need to disconnect the whole conversation?
Thanks and greets, Christian.
Jerome.Saint-Marc | 2023-02-14 15:51:23 UTC | #3
Hello,
I think you would need to use POST /api/v2/conversations/{conversationId}/assign to "manually" assign the conversation to your agent (instead of replace endpoint).
According to this article on manual assignment, the fallback should remain functional if the agent decline or doesn't answer the conversation. "Interactions that are declined or not answered by an agent (timeout threshold reached) are returned to the queue and can be assigned again, until successfully answered."
The Queue needs to be enabled for manual assignment, and the user triggerring the assignment needs proper permissions to manually assign the conversation. Seems to also work with Client Credentials token. The agent needs to be logged in and On Queue - " Agents must be on-queue and in an Idle, Interacting, or Communicating state. Not Responding agents are not eligible."
Initially, this endpoint only allowed to manually assign the conversation to an agent who was member of the current Queue. But this has apparently been extended to assign to users not members of the current Queue. "Waiting interactions can be assigned to agents in the same queue or across queues, or agents can assign an interaction to themselves." I did a quick test with a webchat (to assign a conversation to a CC Agent who was not member of the Queue) and it appeared to work.
Regards,
ciwe | 2023-02-15 06:28:30 UTC | #4
Hello Jerome,
thank you very much for that answer. I made a quick test and got this from the assign API endpoint:
{ "message": "Conversation beb59f89-e05c-4cd5-a78c-c51ded53aa14 does not exist.", "code": "resource.not.found", "status": 404, "messageWithParams": "{entity} {id} does not exist.", "messageParams": { "id": "beb59f89-e05c-4cd5-a78c-c51ded53aa14", "entity": "Conversation" }, "contextId": "56cc1f48-56b6-4be7-a45c-0e0a252340ad", "details": [], "errors": [] }
I wondering about it because interaction is still active and I can receieve and find it over the API: GET /api/v2/conversations/{conversationId}
And there is no end date in the JSON I get for that conversation, means it is still active.
Any ideas?
Thank you and best regards, Christian.
Jerome.Saint-Marc | 2023-02-15 08:54:39 UTC | #5
Hello,
Was this on a new/fresh conversation - in queue at the time of your assign request? Or are you trying to recover an older conversation, that went through your replace/not answering scenario?
My comment on assigning the conversation "manually" to your agent (using the assign API endpoint) was for a new/future conversations, waiting in queue, and then being assigned to your agent using this assign method (instead of the replace endpoint). i.e. email -> workflow -> queue -> manually assign to agent directly
If you have not tried on a fresh/new conversation, I would suggest to try it. To see if using assign endpoint, instead of replace, can help to better manage the scenario you described in your first post.
If the error you posted above is on an "older conversation", I would suggest to open a case with Customer Care, reporting this conversationId. We can't access and can't investigate customer data from this forum. So I don't know what state this conversation is in, if it is "stuck" or an incorrect state, ...
Regards,
ciwe | 2023-02-15 09:46:04 UTC | #6
Hello Jerome,
thank you for your fast answer.
I made my test on an older conversation. So it looks like that that assign API endpoint is not working with such a conversation.
About that assign endpoint with a new conversation in comparison to the replace endpoint I will try today. But a limitation I see is that agents must be on-queue to recieve such a assigned conversation. With replace API endpoint this limitation don't exist.
About my "old" conversation yes I agree and open a Case for it.
Thank you and best regards, Christian.
Andy_Foskett | 2023-03-14 03:40:36 UTC | #7
Hey Christian, Where did this one end up? We're also looking for a solution to find and redirect emails that agents have transferred "into the void". Were you able to find a way to get an alerting email back to a different user or queue? Cheers, Andy
ciwe | 2023-03-15 22:44:25 UTC | #8
Hi,
it ended in the following statement from Customer Care:
I have checked and can see that there is currently an ongoing project with the development team to enhance blind transfers that are declined or ignored causing the interaction to get lost. But we have no timeline at this moment that we share with you. Our recommendation is that you monitor the Features coming soon (next release) as this is the place that will announce it in advance.
Unfortunately, this is a limitation that our development team is aware of and hence there is a current working project to enhance it in the future.
Since this is currently working as designed we will resolve this case, please monitor Features coming soon for the new feature that gets released.
So no satisfied answer I would say...
Greets, Christian.
Andy_Foskett | 2023-03-15 23:45:45 UTC | #9
Hey mate, Thanks for the response. A bit of a downer that they don't have a proper fix yet. I'll keep an eye on the roadmap. In the meantime, we're going to disconnect the interaction, grab it's ID and create a new external email that gets routed to a dead-letter queue monitored by supervisors. When the external email arrives it pops a script that loads the original lost email in the Interactions performance view. A bit ugly, but at least it lets someone pick up the conversation, get back to the customer and have a word to the agent that transferred it into a black hole.
Cheers, Andy
ciwe | 2023-03-31 12:24:24 UTC | #10
Andy_Foskett, post:9, topic:18358
a dead-letter queue monitored by supervisors. When the external email arrives it pops a script that loads the original lost email in the Interactions performance view. A bit ugly, but at least it lets someone pi
In the same way currently our customer made this. Unbelievable that they have to do it like this within Genesys Cloud...
system | 2023-05-01 12:24:42 UTC | #11
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 18358