ConcordAbush | 2020-07-27 22:14:53 UTC | #1
I am working on implementing the PureCloud API's in a manner that allows us to get information about a call when it wraps up. First a little background of what we have tried.
We tried to implement a an Integration Action that is consumed in a Rule that triggers on the end of a call from a campaign. So when a call ends PureCloud sends a push to an endpoint of ours that lets us know call ended for a Contact. Unfortunately the information that is passed back to us does not contain any information that can link back to an actual conversation. The only data that is given to us is a ContactID which maps to the uploaded Contact list the campaign is calling against. This ID does not map to an ExternalContactID.
The current new method we are trying to go down is possibly subscribbing to notificatoins on a Campaign and Queue to see if we can track that back to a wrap-up of a call. This is required so that we can know how the call ended (busy, machine, no answer, or spoke to a agent) in addition the Reason for the calls end which is the Resolution Code when looking at the agent screen. This is a list of states that states when an agent answered how they resolved the call. In addition we are looking to get when the call started and ended and the individual that was contacted along with which Agent answered.
Currently we subscribe to two notification types (StatEventCampaignTopicStatsNotification & QueueConversationEventTopicConversation) but it is not looking like we are getting the right information or even a ConversationID so we can just grab the conversation directly through an API call. We end up getting for a single call on a queue over five notifications through the life of the call.
When we subscribe we are doing the following Campaign: pureCloudConnector.SubscribeToTopic($"v2.outbound.campaigns.{campaign.Id}.stats", typeof(StatEventCampaignTopicStatsNotification), DoAThing);
Queue: pureCloudConnector.SubscribeToTopic($"v2.routing.queues.{distinctQueue}.conversations", typeof(QueueConversationEventTopicConversation), DoAThing);
Are we even subscribing to the right type of notification?
Is this a normal amount of notifications for a single call on a queue?
I understand if this is a confusing post I am somewhat trying to get to a base level of being able to when a call ends get a ConversationID so that we can try and get all the information possible about the call. If this is not the best approach do you recommend a better way to get this information on call completions?
Jerome.Saint-Marc | 2020-07-28 10:16:27 UTC | #2
Hello,
I now understand what you meant by Genesys ContactID in your other post
It is in fact the Outbound Contact ID (id of the contact in the calling list - generated when importing a csv as calling list).
So you can use the Query for Conversation Details with a different dimension in the Segment Filter -> outboundContactId As below:
POST /api/v2/analytics/conversations/details/query With body: { "interval": "2020-06-24T22:00:00.000Z/2020-07-24T22:00:00.000Z", "order": "desc", "orderBy": "conversationStart", "paging": { "pageSize": 25, "pageNumber": 1 }, "segmentFilters": [ { "type": "or", "predicates": [ { "type": "dimension", "dimension": "outboundContactId", "operator": "matches", "value": "youroutboundcontact_id" } ] } ] }
Regarding your question on notification, you would subscribe to the queue which is set/assigned to your campaign. v2.routing.queues.{distinctQueue}.conversations [replacing {distinctQueue} with the queueId that your outbound campaign leverages] In this case, you will indeed receive several notifications per call. What it means is that as soon as a conversation adds this queue as a participant, you will get notification update every time there is a change in the conversation state (that also includes updates when a state of a participant in the conversation changes). Ex: when the conversation enters the queue, exists the queue, adds an agent (ringing, established, ....).
If the approach you had started to take with the Data Action on Outbound Call Rule works for you (I mean if it covers all the cases you wanted to capture), it is probably easier to implement. Given that you should be able to query back the conversations associated with the Outbound Calling List Contact ID (as I posted above).
Regards,
ConcordAbush | 2020-07-28 15:54:55 UTC | #3
Jerome.Saint-Marc, post:2, topic:8406
of the contact in the calling li
Jerome,
With changing of the dimension I was able to pull the conversations for that customer and get a lot of the details that we are looking for. That was way easier I feel than doing the subscription based grabbing in my opinion since it triggers just one item on call end instead of multiple notifications per the life of the call.
I think now I just have to go through on our end and vet all the information that we are getting to ensure everything is there.
Thank you so much for all your speedy replies in this matter.
Jerome.Saint-Marc | 2020-07-28 15:58:31 UTC | #4
You're welcome.
Regards,
system | 2020-08-28 15:58:32 UTC | #5
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: 8406