RjElanga | 2022-07-01 12:10:09 UTC | #1
Hi,
We have a requirement where we leverage the callback api. However , prioritization does not work.
Example:
for example it is 8:00 pm and I scheduled 2 callbacks that are set for 8:05PM
- Priority 0
- Priority 10 or Priority 100
so steps are , I submitted the priority 0 before the 2nd callback with a higher priority. Other fields with the same inputs like scheduled time and etc.
actual behavior:
Priority 0 is still getting offered first before the Higher priority.
Do we have a limitation or this does not work as expected?
Thanks,
RjElanga | 2022-07-01 19:13:05 UTC | #2
I have submitted and created the callbacks with the same scheduled time to tests the scenario.
Even if the starttime would differ (as this refers when the api call initiated the callback creation), the scheduled callbacktime should offer them at the same time and with priorities it should provide the leverage for a couple of minutes to the other callback. Wouldn't that be the expected behavior ?
For example
Call 1 : was initiated at 2022-07-01T18:22:59.194Z - priority 0
Call 2: was initiated at 2022-07-01T18:23:19.695Z - priority 10
but both calls are scheduled at 2022-07-01T18:24:00.00Z , the priority wouldn't be displayed but at the backend it should be able to identify the priority.
callbackScheduledTime (string, optional): The scheduled date-time for the callback as an ISO-8601 string. For example: yyyy-MM-ddTHH:mm:ss.SSSZ
Then as the priority is explained on the knowledge base. Shouldn't it provide the leverage for couple of minutes? I tried testing 100 as well.
it was even included at the requests for the routing data when you send a request to /api/v2/conversations/callbacks and description provided was "priority (integer, optional): The priority for routing" . Unless the callback disregards the priority? Same as disregarding the ACW timeout setup for the queues.
This is what confusing me as the documentation provided this information.
RjElanga | 2022-07-01 19:13:59 UTC | #3
Created 2 callbacks as of now , Screenshot is UTC+8
{ "scriptId": "cbb976ff-f7de-45a6-8b88-c259e1f080c9", "routingData": { "queueId": "52f09ab2-903b-4cac-8cd4-aa4c769c267d", "priority": 100, "routingFlags": [] }, "callbackUserName": "RJ TEST 100", "callbackNumbers": ["+639177949721"], "callbackScheduledTime": " 2022-07-01T19:04:28+0000", "validateCallbackNumbers": true
}
Same format , different Username and priority
Checked /api/v2/conversations/{conversationId}
741d263f-d3e5-40d3-b74a-8fc8f7e3ba1e prio 0
"participantId": "c26ea7d1-09e5-484c-bf77-0a1fcaed1728", "purpose": "acd", "sessions": [ { "agentBullseyeRing": 1, "callbackNumbers": [ "+639177949721" ], "callbackScheduledTime": "2022-07-01T19:04:28Z", "callbackUserName": "RJ TEST", "direction": "outbound", "mediaType": "callback", "peerId": "6cb36be1-6df1-4a07-95f0-55a322fd15d8", "provider": "PureCloud Callback", "remote": "RJ TEST", "requestedRoutings": [ "Bullseye" ],
a4c17caa-652e-4312-961f-c2c80cf13fdf prio 100
{ "participantId": "498d37ef-9640-4c02-a953-8de823681154", "purpose": "acd", "sessions": [ { "agentBullseyeRing": 1, "callbackNumbers": [ "+639177949721" ], "callbackScheduledTime": "2022-07-01T19:04:28Z", "callbackUserName": "RJ TEST 100", "direction": "outbound", "mediaType": "callback", "peerId": "5a132328-868d-4085-a079-7a0858e7a117", "provider": "PureCloud Callback", "remote": "RJ TEST 100", "requestedRoutings": [ "Bullseye" ],
But still the prio 0 was offered first.
Brad_Murlin | 2022-07-08 15:08:05 UTC | #4
It looks like you are doing things correctly, but the Genesys folks in this forum cannot troubleshoot an API behaving badly, they can only help us use them correctly -- for an API that is being used right, but not acting proper, you'll need to open a support case with Genesys care.
In the interim - you can technically set callbacks in the past -- you could set the callback time to be older based on priority. IE if you want both callbacks at 10AM, and it is 9:59 right now - schedule the priority one for 9:57 and it will enter the queue as if it had been there for a few minutes, essentially doing the same job as the priority value is supposed to be doing.
RjElanga | 2022-07-01 20:20:38 UTC | #5
Thank you, just raised a case to support for this.
Meanwhile I will look for a different approach as you have suggested. Might be messy with the logic as we will need to manipulate values and the requirements limit us at leveraging the scripts only as these are agent initiated callbacks but I will check.
Thanks again
John_Carnell | 2022-07-08 15:08:09 UTC | #6
This post was migrated from the old Developer Forum.
ref: 15364