Set Skills action inside of an In-queue flow does not work reliably when Agents use auto-answer and WebRTC phone

Genesys Cloud Applications
1

I'm looking for help after spending days troubleshooting this issue to see how to resolve it.

We are using “Set Skills” action inside of an In-queue Flow in Genesys Cloud Architect where we're experiencing issues with the skills not being set on some calls that enter the In-queue flow.

Can you please confirm if the "Set Skills" action needs to meet specific criteria for it to set a skill for every interaction that enters an In-queue flow?

We have agents who are part of a queue that use WebRTC phones with Auto-answer enabled. This means that if a call enters a queue and an agent is available, the call is immediately connected to the agent and auto-answered.

Will the “Set Skills” action inside the In-Queue flow have enough time to run and set the right skills in this case?

Will the Queue routing method have time to consider the new skills and use them to decide which agent to deliver the call to? Or is there a chance that the skills don’t get attached in time because agents are immediately available and they use auto-answer?

The reason why I’m asking about the detail of how the Set Skills action functions inside of an In-Queue flow when agents use auto-answer is that we have been testing this and it does not always work. Some calls, at random, are missing skills that are meant to be attached by the “Set Skills” action.

From our testing, we have noticed that if we put the “Set skill“ action towards the end of the In-queue flow, which has multiple steps with data table lookups, decisions, setting and getting participant data, data action lookups using Genesys APIs, and message playbacks, the number of calls with skills not set dramatically increases. This is only affecting calls that are immediately auto-answered by an available agent in the queue. Only about 1 in 10 calls have the skills attached correctly in that case. If there is no agent available straight away, and the caller waits in the queue for a couple of seconds, the skill gets correctly attached every time.

Putting the “Set skill“ action closer to the top of the In-queue flow, increases the success rate of it working and setting the skills on most of our calls. About 9 in 10 calls have skills attached correctly.

But, when we disable auto-answer on Agent’s WebRTC phones, or when Agents use “Remote phone“ set to their mobile number, then all of the calls entering the In-queue flow have all skills attached every time.

It seems as if the Queue routing engine is connecting the call to an available Agent too quickly when auto-answer is enabled, resulting in the "Set Skills" action not executing or completing correctly.

To try and determine if the In-queue flow gets only partially executed, whether only some of the steps/actions/data table lookups have time to execute before the call is auto-answered by an Agent, we have used Set participant data actions throughout the In-queue flow to add attributes.

The result was that almost all calls have all participant data values attached inside of the Conversation ID when queried from the Analytics Conversation Details API endpoint and also inside the Genesys Cloud Interaction detail page under Participant Data.

That makes us believe the whole In-queue flow executed correctly in that split of a second when the call connected to the queue and was immediately auto-answered by an available Agent.

Only on one occasion, we've seen that none of the participant attributes from the whole in-queue flow got tagged on the interaction.

This left us with two different behaviours when the issue happens. One where all participant attributes show (the whole in-queue flow was executed) or none of the participant attributes show (the in-queue flow was not executed) but the In-queue flow does show as being part of the Conversation segments when we query Analytics Conversation Details API endpoint.

We use one of the participant attributes called “transferSkillSet“ to tag the success and failure paths of the “Set skills“ action to confirm which path was used for the call. All calls take the SUCESS path, even those that are missing the skills that are meant to be set by this action.

The call scenario is:

A client calls into Inbound IVR and selects one of the IVR options. The call is delivered to QUEUE1 using Architect Inbound Call flow "Go to queue" action where we also tag the call with SKILL1. The call is routed and auto-answered by AGENT1 which has the SKILL1 assigned.

Unfortunately, AGENT1 does not have clearance to deal with the client's query and they blind transfer the call to QUEUE2 for escalation. We have the Genesys ORG setup to strip skills on blind transfer. At this point, when the call is transferred to QUEUE2, the IN-QUEUE flow is configured to set SKILL2 and SKILL3 using the "Set skills" action and then let the call wait to get answered while listening to Music on hold and Periodic announcements. The in-queue flow that is used when agent blind transfers from QUEUE1 into QUEUE2 is set in the QUEUE2 settings in Genesys Cloud Admin > Contact Center > Queues > QUEUE2 > Voice > In-queue flow.

Note:
We have tested the same call scenario using Consult transfer and got the same results. Some calls were missing the skills from the in-queue flow and some had it set.

What we can see in the Analytics Conversation Details API output for the working call with all skills set is that the transfer from QUEUE1 to QUEUE2 has the “requestedRoutingSkillIds” section with both SKILL2 and SKILL3 added in the "Interact" segment type. See lines 13-15.

1 "segments": [
2 {
3 "conference": false,
4 "queueId": "2e2efd3d-18a6-4ae9-b5fd-aa65ec759daa",
5 "segmentEnd": "2023-02-22T18:09:38.889Z",
6 "segmentStart": "2023-02-22T18:09:38.886Z",
7 "segmentType": "delay"
8 },
9 {
10 "conference": false,
11 "disconnectType": "transfer",
12 "queueId": "2e2efd3d-18a6-4ae9-b5fd-aa65ec759daa",
13 "requestedRoutingSkillIds": [
14 "5c8d5f0d-a8e1-4caf-b520-8d8a8be4fb54",
15 "aa0c4417-cf10-4713-8376-e85d85aab604"
16 ],
17 "segmentEnd": "2023-02-22T18:09:39.827Z",
18 "segmentStart": "2023-02-22T18:09:38.889Z",
19 "segmentType": "interact",
20 "sipResponseCodes": [
21 410
22 ]

The “requestedRoutingSkillIds” section is also added under each of the segment types "Alert, Interact, Wrapup" when the call enters the QUEUE2. See lines 5-7, 17-19, 29-31.

1 "segments": [
2 {
3 "conference": false,
4 "queueId": "2e2efd3d-18a6-4ae9-b5fd-aa65ec759daa",
5 "requestedRoutingSkillIds": [
6 "5c8d5f0d-a8e1-4caf-b520-8d8a8be4fb54",
7 "aa0c4417-cf10-4713-8376-e85d85aab604"
8 ],
9 "segmentEnd": "2023-02-22T18:09:39.854Z",
10 "segmentStart": "2023-02-22T18:09:39.152Z",
11 "segmentType": "alert"
12 },
13 {
14 "conference": false,
15 "disconnectType": "client",
16 "queueId": "2e2efd3d-18a6-4ae9-b5fd-aa65ec759daa",
17 "requestedRoutingSkillIds": [
18 "5c8d5f0d-a8e1-4caf-b520-8d8a8be4fb54",
19 "aa0c4417-cf10-4713-8376-e85d85aab604"
20 ],
21 "segmentEnd": "2023-02-22T18:09:45.510Z",
22 "segmentStart": "2023-02-22T18:09:39.854Z",
23 "segmentType": "interact"
24 },
25 {
26 "conference": false,
27 "disconnectType": "client",
28 "queueId": "2e2efd3d-18a6-4ae9-b5fd-aa65ec759daa",
29 "requestedRoutingSkillIds": [
30 "5c8d5f0d-a8e1-4caf-b520-8d8a8be4fb54",
31 "aa0c4417-cf10-4713-8376-e85d85aab604"
32 ],
33 "segmentEnd": "2023-02-22T18:09:49.275Z",
34 "segmentStart": "2023-02-22T18:09:45.275Z",
35 "segmentType": "wrapup",
36 "wrapUpCode": "6257627f-778f-4ae7-951d-cc4624c364ee"
37 }

On the other hand, the output from the Analytics Conversation Details API for the call with missing skills is that the transfer from QUEUE1 to QUEUE2 does not include the “requestedRoutingSkillIds” section where both SKILL2 and SKILL3 should be present in the "Interact" segment type. See lines 10-17.

1 "segments": [
2 {
3 "conference": false,
4 "queueId": "2e2efd3d-18a6-4ae9-b5fd-aa65ec759daa",
5 "segmentEnd": "2023-02-22T17:59:07.737Z",
6 "segmentStart": "2023-02-22T17:59:07.693Z",
7 "segmentType": "delay"
8 },
9 {
10 "conference": false,
11 "disconnectType": "transfer",
12 "queueId": "2e2efd3d-18a6-4ae9-b5fd-aa65ec759daa",
13 "segmentEnd": "2023-02-22T17:59:08.365Z",
14 "segmentStart": "2023-02-22T17:59:07.737Z",
15 "segmentType": "interact",
16 "sipResponseCodes": [
17 410
18 ]

The “requestedRoutingSkillIds” section is also missing from each of the segment types "Alert, Interact, Wrapup" when the call enters QUEUE2. See below.

1 "segments": [
2 {
3 "conference": false,
4 "queueId": "2e2efd3d-18a6-4ae9-b5fd-aa65ec759daa",
5 "segmentEnd": "2023-02-22T17:59:08.364Z",
6 "segmentStart": "2023-02-22T17:59:07.935Z",
7 "segmentType": "alert"
8 },
9 {
10 "conference": false,
11 "disconnectType": "peer",
12 "queueId": "2e2efd3d-18a6-4ae9-b5fd-aa65ec759daa",
13 "segmentEnd": "2023-02-22T17:59:14.030Z",
14 "segmentStart": "2023-02-22T17:59:08.364Z",
15 "segmentType": "interact"
16 },
17 {
18 "conference": false,
19 "disconnectType": "peer",
20 "queueId": "2e2efd3d-18a6-4ae9-b5fd-aa65ec759daa",
21 "segmentEnd": "2023-02-22T17:59:20.953Z",
22 "segmentStart": "2023-02-22T17:59:13.953Z",
23 "segmentType": "wrapup",
24 "wrapUpCode": "6257627f-778f-4ae7-951d-cc4624c364ee"
25 }

Please let me know if you have any suggestions on how this could work reliably for our call scenario without disabling auto-answer for Agents using WebRTC phones.

The only solution we found that reliably attaches Skills inside In-queue flow using "Set skills" action is to not use auto-answer functionality, which is not an option for our client.

To add to the full picture, the reason we use skills inside of queues is mainly because of these 2 requirements:

  1. Our customer uses 3rd party WFM system that integrates with Genesys Cloud over API, but it only reports on and creates forecasts based on Skills. Thus each call needs to have a skill attached and each agent needs to have a skill assigned.

  2. The customer has built an external reporting tool that pulls all data from Genesys Cloud Analytics API and monitors the Notifications API. Their reporting is built around Skills, not Queues. Thus they also need to see all conversations with skills assigned.

That's the main reason why we are trying to assign new skills to a call when it's transferred to another queue. To make sure the correct skills are added for their WFM and Reporting systems to know the call had SKILL1 assigned in Queue1 and SKILL2 + SKILL3 assigned in Queue2.

Thank you for your help.

2

Please open a case with Genesys Cloud Care to investigate routing and assignment issues, like skills not being assigned per the expected routing or conversations not being assigned when you believe they should be. That investigation requires access to your data that we do not have via the forum.

3

We did more than a month ago, but it never led anywhere. We were told the call flows we use are too complex.

Now we've reconfigured the transfer in-queue flow to simplify it and we're getting this issue with "Set skills" action not working. This only happens if agents use auto answer and there is agent immediatelly available to take the call.

We've raised this issue in a new case with Care yesterday. Lets see where it leads.

Generally speaking, do you know if the "Set skills" action in the in-queue flow has any limitations?
Or should it always assign skills regardles if agents use auto-answer and the call is immediatelly answered when it enters the queue?

Thanks

4

An In-queue Callflow does not provide an guarantee of execution of the blocks within the call flow. The call flow will end abruptly once an agent is available. In the case of an available agent using auto answer it is likely the callflow wouldn't execute at all.

If you need a guarantee of execution of all the blocks in the in-queue call flow in an agent transfer scenario, then you should use a 2 queue strategy. The first agent might transfer the call to the "Billing" queue which has no member agents. The in-queue flow will execute all blocks, and the last block should be a "Transfer to ACD" block to send the call to the "Billing (Agents)" queue that actually has member agents that will be on-queue. That is the only way to guarantee that your in-queue callflow will fully execute all actions before an agent would be able to interrupt the callflow.

5

Thank you for coming back to me. That confirms what we were seeing, when an agent is available on a queue with WebRTC and auto-answer enabled, the call doesn't have enough time to go through the in-queue flow and set the skill using "Set skills" action, resulting in some calls not having skills tagged.

The solution with 2 queues is something we considered before, but our problem with this approach is that it relies on users doing the right thing. Based on our experience, users would at times transfer to one queue, other times to the other queue and we would end up again with some calls with skills attached and others without.

I was hoping to find a solution that doesn't rely on users doing something specific as that is never guaranteed.

Before we used a setup where the call was transferred by an agent from QUEUE1 to QUEUE2 as a blind or consult transfer. The ORG is setup to strip skills on Blind transfer.
The QUEUE2 had all the agents in it, but it was configured with default in-queue flow that automatically sent the call to Inbound flow which then used "Go to queue" action and sent the call back to QUEUE2 with attached new skills, and set different In-queue flow so the call doesn't end in a constant loop by exiting and entering the QUEUE2.

This solution worked for some time, calls were entering the QUEUE2, exiting and immediately entering QUEUE2 again. It was attaching new skills and agents were part of the same queue so there was no major risk of human error on transfer. This was built before the "Set skills" action was available inside in-queue flows.

Problem is that it stopped working at some point, and when the issue was raised to us by the client, we found that now almost no calls are tagged with skills using this flow process. We raised it with Genesys care, but unfortunately didn't get anywhere.

I think we'll have to tweak the In-queue flow to make sure it's as simple and short as it can be. It seems then tagging of new skills works almost every time, even when agents use auto-answer.

6

If anyone comes across this issue in future where they need to tag a skill after transfer to match the destination queue agent base and route with correct skills, or they simply need it for reporting using external applications like Power BI, or they need it for external integration to WFM systems that are based on skill tagging, not queue assignment, then I found the problem with the original approach we've been using for last 2 years.

The setup we had before skills could be tagged inside in-queue flows was based on enabling the stripping of a skill using Blind transfer on the ORG level. When agents used consult transfer, skills were stripped automatically by Genesys. We had an in-queue flow setup as default on each queue to transfer the incoming call to inbound call flow that would then attach the correct skill based on the queue name the call was transferred to and data table lookup to know what skills to attach. The call was then returned to the same queue, but set to use a different in-queue flow that simply allowed the client to wait and listen to MOH.

The reason this stopped working was at the end down to a different Queue routing method.
From the day we deployed this, all queues used the Standard routing method.
The client changed this to Bulls Eye routing a couple of months ago and ever since it was not tagging the transfer skills even though the call flow setup was exactly the same.

The reason for this seems to be down to Genesys system performance, as far as I can see, but that's an assumption based on results I've seen when testing in DEV org with small to no load and in a production environment with 700 agents and 700 communicate users.

The issue boiled down to the fact that the whole transfer process from the time the call enters the destination queue, the in-queue flow transfers it out to inbound call flow that attaches the correct transfer skill and then the call joins the SAME queue again with different in-queue flow that allows client to wait in the queue takes hundreds of milliseconds. I was checking each step of the conversation using the Genesys /api/v2/conversations/calls/{conversationId} and found that if the queue used Standard routing, it always correctly attached skills. When we switched to Bulls Eye routing, the transfer skills were almost always missed.
Surprisingly when there were almost no agents logged in the system overnight, only a skeleton crew to handle calls on some lines that are open 24/7, the transfer skills worked fine even using the Bulls Eye routing logic. This makes me think it's load related and how quickly each different queue routing method responds to the internal Genesys processes when the call is transferred into the queue, kicked out and then routes back into the same queue. It seems that during a day when there are many users logged into queues during open hours, the Bulls Eye routing strategy takes longer to decide which agent is the next to get the call, the call is then kicked out of the queue and when it comes back it's missing transfer skills, even though the call flow action should assign them. With standard routing, this always works even during busy open hours.

I'm judging by my experience with testing skill attachment inside in-queue flow (more recently added feature to Genesys Cloud), if the in-queue flow is long with many data actions etc. it sometimes misses the skill attachment, when we tested during busy open hours, but when we tested with almost no load on the Genesys ORG, it almost always attached skill without issues.

Now back to the Standard routing vs Bulls Eye Routing and transfer from queue, to call flow, back to the same queue. The difference I've seen in the Conversation API between two test calls (I made hundreds of test calls :sweat_smile:) was down to the original skill not being shown upon the call joining the transfer queue.
Meaning when a client call joins the original queue with skill sales, even though we have the Genesys ORG set to strip the skill upon blind transfer (and it strips it by default upon Consult transfer) it still for some reason shows in the API as joining the transfer queue with the original skill. This is not shown in Skills reporting under Performance, but it is shown in the Conversation API. If this original skill is not tagged on the transfer queue, and the call exits the queue before it has time to do it, when the call returns with a new transfer skill in next hundreds of milliseconds, these skills are not attached to the call. They aren't shown in the Conversation API, nor in the Skills reporting in Genesys.

The second experience we've seen in the Conversation API for call that always got transfer skills attached was when the transfer queue had enough time to decide which agent to give the call to, the Agent step was logged in the API result and then immediately the call was kicked out of the queue (before even agent could see the call ringing on their browser) and then join back in. This time the call joining the transfer queue for the first time after agent transfer didn't have the original skill shown in the API result. But as soon as it has shown the agent name that is going to connect to transfer skill was attached correctly upon return to the queue.

When we used the Bulls Eye routing method, the issue with missing transfer skills happened almost every time when we tested on a busy ORG (1000+ users), but when we tested in a DEV ORG with less than 10 users logged in and hardly taking any calls, it worked some of the time.

All in all, somehow Standard routing method seems to help the internal Genesys process to perform all necessary activities quickly enough to tag the original skill or decide on which agent to route to before the call is kicked out of the queue and returned back with new transfer skills. The whole process of leaving the queue, attaching transfer skills, and joining the queue again, takes hundreds of milliseconds and I think that's the culprit here. Unfortunately, we can't add a couple of seconds of wait time to the in-queue flow upon transferring the call into the queue by an agent for the first time, because we use auto answer and if an agent is available, the WebRTC phone would be quicker than the transfer process and it would answer the call before tagging new transfer skills.

It's a very specific situation that not many might come across, so I thought to explain as best as possible without going into each scenario that we tested. It took a good few weeks to work this one out.

This is part of the result from Conversation API when a call joins the transfer queue after an agent from another queue transfers it, and it doesn't show the original skill or agent selected in the queue. This is where we saw the issue manifest itself in the Conversation API results.

I didn't include the API result where an agent answered the call in ORIGINAL_QUEUE with ORIGINAL_SKILL.
Below you'll see the part where the agent transferred the call and it joined the TANSFER_QUEUE that then should attach TRANSFER_SKILLS, but it didn't work. Transfer skills are shown in custom attributes upon returning to TRANSFER_QUEUE, because data table lookup worked in the inbound call flow, but the skills are not attached to the queue upon return. Yet priority got updated correctly.

TRANSFER SKILLS not attached:

{
"id": "ec2c3455-f655-4e46-ad02-XXX",
"name": "TRANSFER_QUEUE",
"address": "sip:XXXb5-87f8-416a-a9c4-XXX@127.0.0.1;language=en-US;src=https://edge-proxy.XXX/defaultentrypoint.vxml;user=acd",
"startTime": "2023-02-15T22:55:54.750Z",
"connectedTime": "2023-02-15T22:55:54.796Z",
"endTime": "2023-02-15T22:55:55.173Z",
"purpose": "acd",
"state": "terminated",
"direction": "inbound",
"disconnectType": "transfer",
"held": false,
"wrapupRequired": false,
"mediaRoles": [],
"queue": {
"id": "bcae3fb5-87f8-416a-a9c4-XXX",
"selfUri": "/api/v2/routing/queues/bcae3fb5-87f8-416a-a9c4-XXX"
},
"attributes": {
** "ivr.Priority": "5",** - ORIGINAL_PRIORITY reported in attributes
** "ivr.Skills": "cf5c484c-ef46-4628-aea4-409a2266e1ee"** - ORIGINAL_SKILL reported in attributes
},
"provider": "Edge",
"peer": "b3fa0f85-cf09-4c7f-a5f6-XXX",
"conversationRoutingData": {
"queue": {
"id": "bcae3fb5-87f8-416a-a9c4-XXX",
"selfUri": "/api/v2/routing/queues/bcae3fb5-87f8-416a-a9c4-XXX"
},
"priority": 5, - Showing ORIGINAL_PRIORITY from ORIGINAL_QUEUE. Thought it should be stripped with skill upon transfer.
"skills": [], - No skill upon joining the TRANSFER_QUEUE
"scoredAgents": []
},
"muted": false,
"confined": false,
"recording": false,
"recordingState": "none",
"ani": "tel:XXX",
"dnis": "sip:bcae3fb5-87f8-416a-XXX@127.0.0.1;language=en-US;src=XXX/defaultentrypoint.vxml;user=acd"
},
{
"id": "99fc9906-55cd-4027-XXX",
"name": "TRANSFER_CALL_FLOW",
"address": "sip:99b30780-c141-4801-80b9-XXX@127.0.0.1;language=en-US;user=ivr",
"startTime": "2023-02-15T22:55:55.169Z",
"connectedTime": "2023-02-15T22:55:55.172Z",
"endTime": "2023-02-15T22:55:56.343Z",
"purpose": "ivr",
"state": "terminated",
"direction": "inbound",
"disconnectType": "transfer",
"held": false,
"wrapupRequired": false,
"mediaRoles": [],
"attributes": {},
"provider": "Edge",
"peer": "b3fa0f85-cf09-4c7f-a5f6-XXX",
"muted": false,
"confined": false,
"recording": false,
"recordingState": "none",
"ani": "tel:XXX",
"dnis": "sip:99b30780-c141-4801-80b9-XXX@127.0.0.1;language=en-US;user=ivr"
},
{
"id": "fa697a87-88a5-4f6f-85cc-XXX",
"name": "TRANSFER_QUEUE",
"address": "sip:bcae3fb5-87f8-416a-a9c4-XXX@127.0.0.1;language=en-US;src=XXX/defaultentrypoint.vxml;user=acd",
"startTime": "2023-02-15T22:55:56.346Z",
"connectedTime": "2023-02-15T22:55:56.393Z",
"endTime": "2023-02-15T22:56:41.279Z",
"purpose": "acd",
"state": "terminated",
"direction": "inbound",
"disconnectType": "transfer",
"held": false,
"wrapupRequired": false,
"mediaRoles": [],
"queue": {
"id": "bcae3fb5-87f8-416a-a9c4-XXX",
"selfUri": "/api/v2/routing/queues/bcae3fb5-87f8-416a-a9c4-XXX"
},
"attributes": {
** "ivr.Priority": "70",** - Correct new TRANSFER_PRIORITY shown in attributes, after lookup in data tables
** "ivr.Skills": "308dd055-2643-4afd-bf5e-7d8bb2d4d2eb,632d79cf-fa56-4a1a-9241-f7a599544a85"** - Correct new TRANSFER_SKILLS shown in attributes, after lookup in data tables
},
"provider": "Edge",
"peer": "b3fa0f85-cf09-4c7f-a5f6-XXX",
"conversationRoutingData": {
"queue": {
"id": "bcae3fb5-87f8-416a-a9c4-XXX",
"selfUri": "/api/v2/routing/queues/bcae3fb5-87f8-416a-XXX"
},
"priority": 70, - Correct TRANSFER_PRIORITY tagged in TRANSFER_QUEUE, after joining again
"skills": [], - NO TRANSFER_SKILL tagged in TRANSFER_QUEUE, after joining again
"scoredAgents": []
},
"muted": false,
"confined": false,
"recording": false,
"recordingState": "none",
"ani": "tel:XXX",
"dnis": "sip:bcae3fb5-87f8-416a-XXX@127.0.0.1;language=en-US;src=XXX/defaultentrypoint.vxml;user=acd"
},

Conversation API output for a call with WORKING TRANSFER_SKILL:

Call part where agent answered in ORIGINAL_QUEUE with ORIGINAL_SKILL not shown. Only after they transferred to TRANSFER_QUEUE.

{
  "id": "86789036-aff9-4776-aef9-XXX",
  "name": "TRANSFER_QUEUE",
  "address": "sip:bcae3fb5-87f8-416a-a9c4-XXX@127.0.0.1;language=en-US;src=XXX/defaultentrypoint.vxml;user=acd",
  "startTime": "2023-02-16T14:12:57.011Z",
  "connectedTime": "2023-02-16T14:12:57.051Z",
  "endTime": "2023-02-16T14:12:57.490Z",
  "purpose": "acd",
  "state": "terminated",
  "direction": "inbound",
  "disconnectType": "transfer",
  "held": false,
  "wrapupRequired": false,
  "mediaRoles": [],
  "queue": {
    "id": "bcae3fb5-87f8-416a-a9c4-XXX",
    "selfUri": "/api/v2/routing/queues/bcae3fb5-87f8-416a-XXX"
  },
  **"attributes": {**

** "ivr.Priority": "5",** - Showing ORIGINAL_PRIORITY from ORIGINAL_QUEUE in custom attributes.
** "ivr.Skills": "cf5c484c-ef46-4628-aea4-409a2266e1ee"** - Showing ORIGINAL_SKILL from ORIGINAL_QUEUE in custom attributes.
},
"provider": "Edge",
"peer": "c8f819cf-8923-487b-9b96-XXX",
"conversationRoutingData": {
"queue": {
"id": "bcae3fb5-87f8-416a-a9c4-XXX",
"selfUri": "/api/v2/routing/queues/bcae3fb5-87f8-416a-a9c4-XXX"
},
"priority": 5, - Showing ORIGINAL_PRIORITY from ORIGINAL_QUEUE. Thought it should be stripped with skill upon transfer.
** "skills": [],**
"scoredAgents": []
},
"muted": false,
"confined": false,
"recording": false,
"recordingState": "none",
"ani": "tel:XXX",
"dnis": "sip:bcae3fb5-87f8-416a-a9c4-XXX@127.0.0.1;language=en-US;XXX/defaultentrypoint.vxml;user=acd"
},
{
"id": "86958bce-9deb-4fa0-9ef8-XXX",
"address": "tel:+XXX;tgrp=3c924370-7fdf-4577-931e-XXX;trunk-context=nttm1suat",
"startTime": "2023-02-16T14:12:57.290Z",
"endTime": "2023-02-16T14:12:57.453Z",
"purpose": "agent", - Here we can see that additional step compared to a CALL WITH NON WORKING TRANSFER SKILLS. The call was connecting to an agent before it was sent out of the queue using transfer action inside in-queue flow to route to inbound flow to attach transfer skills and then return back to transfer queue.
"state": "terminated",
"direction": "inbound",
"disconnectType": "peer",
"held": false,
"wrapupRequired": false,
"wrapupPrompt": "timeout",
"mediaRoles": [
"full"
],
"user": {
"id": "535be0e7-cae8-4340-bc5b-XXX",
"selfUri": "/api/v2/users/535be0e7-cae8-4340-bc5b-XXX"
},
"queue": {
"id": "bcae3fb5-87f8-416a-a9c4-XXX",
"selfUri": "/api/v2/routing/queues/bcae3fb5-87f8-416a-XXX"
},
"attributes": {},
"wrapupTimeoutMs": 120000,
"alertingTimeoutMs": 15000,
"provider": "Edge",
"peer": "c8f819cf-8923-487b-9b96-XXX",
"muted": false,
"confined": false,
"recording": false,
"recordingState": "none",
"ani": "sip:XXX;user=phone",
"dnis": "tel:XXX;trunk-context=nttm1suat"
},
{
"id": "0fe8db0b-683d-4406-af27-XXX",
"name": "TRANSFER_CALL_FLOW",
"address": "sip:99b30780-c141-4801-80b9-XXX@127.0.0.1;language=en-US;user=ivr",
"startTime": "2023-02-16T14:12:57.486Z",
"connectedTime": "2023-02-16T14:12:57.489Z",
"endTime": "2023-02-16T14:12:58.588Z",
"purpose": "ivr",
"state": "terminated",
"direction": "inbound",
"disconnectType": "transfer",
"held": false,
"wrapupRequired": false,
"mediaRoles": [],
"attributes": {},
"provider": "Edge",
"peer": "c8f819cf-8923-487b-XXX",
"muted": false,
"confined": false,
"recording": false,
"recordingState": "none",
"ani": "tel:XXX",
"dnis": "sip:99b30780-c141-4801-XXX@127.0.0.1;language=en-US;user=ivr"
},
{
"id": "a7e29223-1a99-43e7-XXX",
"name": "TRANSFER_QUEUE",
"address": "sip:bcae3fb5-87f8-416a-a9c4-XXX@127.0.0.1;language=en-US;src=XXX/defaultentrypoint.vxml;user=acd",
"startTime": "2023-02-16T14:12:58.594Z",
"connectedTime": "2023-02-16T14:12:58.603Z",
"endTime": "2023-02-16T14:13:02.774Z",
"purpose": "acd",
"state": "terminated",
"direction": "inbound",
"disconnectType": "transfer",
"held": false,
"wrapupRequired": false,
"mediaRoles": [],
"queue": {
"id": "bcae3fb5-87f8-416a-XXX",
"selfUri": "/api/v2/routing/queues/bcae3fb5-87f8-416a-XXX"
},
"attributes": {
"ivr.Priority": "70", - New TRANSFER_PRIORITY showing in attributes
** "ivr.Skills": "308dd055-2643-4afd-bf5e-7d8bb2d4d2eb,632d79cf-fa56-4a1a-9241-f7a599544a85"** - New TRANSFER_SKILLS showing in attributes
},
"provider": "Edge",
"peer": "c8f819cf-8923-487b-9b96-8ee73110ac3e",
"conversationRoutingData": {
"queue": {
"id": "bcae3fb5-87f8-416a-a9c4-088c20da98ea",
"selfUri": "/api/v2/routing/queues/bcae3fb5-87f8-416a-a9c4-088c20da98ea"
},
"priority": 70, - New TRANSFER_PRIORITY attached to TRANSFER_QUEUE
"skills": [
** {**
** "id": "308dd055-2643-4afd-bf5e-7d8bb2d4d2eb",** - New TRANSFER_SKILL attached to TRANSFER_QUEUE
** "selfUri": "/api/v2/routing/skills/308dd055-2643-4afd-bf5e-7d8bb2d4d2eb"**
** },**
** {**
** "id": "632d79cf-fa56-4a1a-9241-f7a599544a85",** - New TRANSFER_SKILL attached to TRANSFER_QUEUE
** "selfUri": "/api/v2/routing/skills/632d79cf-fa56-4a1a-9241-f7a599544a85"**
** }**
],
"scoredAgents": []
},
"muted": false,
"confined": false,
"recording": false,
"recordingState": "none",
"ani": "tel:XXX",
"dnis": "sip:bcae3fb5-87f8-416a-a9c4-XXX@127.0.0.1;language=en-US;src=XXX/defaultentrypoint.vxml;user=acd"
},

If anyone has any questions, feel free to reach out.

Thanks

7

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.