History
In a previous article I wrote about how to use conversation topics to detect a Preview Accepted Event, and leverage this event in an orchestration workflow. [ Preview Dialer Trigger ] . This guide will assist with filling out some additional gaps in the " Preview Mode " for the dialer, specifically automatic retries.
Important facts to consider
- Call Rules execute only when the the agent elects to dial the Preview Contact Offered
- This means the preview offer & presentation to the guide cannot be orchestrated by call rules
- any contact record manipulation in pre-call or wrap-up rules will not have an effect until the Agent elects to dial the contact
- Wrap-up/Disposition of the conversation does not "close" the preview
- Automatic Retries do not work for Preview contacts
- I aim to describe an opinionated design that solves this problem here
Solution
Approach
When the preview/callback is closed there is no direct correlating event fired from a outbound notification topic, however there is a a topic that exposes an event that reflects the user closed the preview v2.detail.events.conversation.{id}.user.end which produces the event payload referenced below.
{
"eventTime": 1769706784067,
"conversationId": "f110e31a-0567-4ad4-bb60-ace2dc50946b",
"participantId": "1686d529-846f-4492-a750-e887c2fe5f2a",
"sessionId": "65b7c13f-d144-4407-9719-f98333df7cf8",
"disconnectType": "CLIENT",
"mediaType": "CALLBACK",
"provider": "PureCloud Callback",
"direction": "OUTBOUND",
"callbackUserName": "Customer",
"callbackNumbers": [
"+15555551234"
],
"userId": "8c677bc-c2a9-4d18-886b-d36813c5e3e9",
"divisionId": "21814508-f50b-47b0-b18f-f64c98daff3f",
"queueId": "c67cc289-4471-4777-9e23-45e89c109d58",
"interactingDurationMs": 122659,
"heldDurationMs": 0,
"alertingDurationMs": 4987,
"contactingDurationMs": 0,
"dialingDurationMs": 0,
"callbackDurationMs":16917
}
In this payload we identified attributes to leverage in the trigger "Callback/Preview End Event" conditions to isolate the specific events we need, its a start but not perfect as we do not have any outbound attributes to correlate the event to a conversation, contact list, or campaign.
JSON Path Operator Value
disconnectType == "CLIENT"
mediaType == "CALLBACK"
provider == "PureCloud Callback"
direction == "OUTBOUND"
But, how do we tie this event back to a Preview contact and list ?
Well, the previous article I wrote described how to capture a Preview "accepted" event [ Preview Dialer Trigger ] , we add a data action to insert a record into a data table, then added that data action to our previous workflow which inserts the phoneNumber, contactId, and contactListId to the data table called preview_contact_retries.
THEN
In our new workflow attached to our Callback/Preview End Event trigger will compare the number in the v2.detail.events.conversation.{id}.user.end payload to the preview_contact_retries data table (where phoneNumber is the primary-key for the table). If a match is found, then we need to fetch the wrap-up value from the record in the contact list, we already have a data-action that will fetch contact-list records by contactId. & contactListId. [/api/v2/outbound/contactlists/{contactListId}/contacts/{contactId}]
then we have a separate data-table that stores the wrapup codes that are eligible for "retries" we'll call preview_retries_wrap_policy
pkWrapupString waitTime
ININ-OUTBOUND-PREVIEW-SKIPPED 240
If the wrap-up/disposition from the contact record in the contact-list matches a row in this table, we pull the waitTime value into our flow. Now we can glue everything together. We have a data action which implements POST:/api/v2/outbound/contactlists/{contactListId}/contacts , we use that data-action to re-submit the contact body back into the contact-list which updates the createdAt timestamp of the contact in the list triggering the dialer to process a "retry" ONLY after the waitTime has expired.
This is currently running in production today and is appropriately handling "retries" through the dialer. Because of our SalesForce Service Cloud Voice integration dependencies the traditional "Scheduled Callback" feature of the platform would not work for us as the contactID in our contact-list must match the Salesforce OpportunityID set when the contact was forwarded from Salesforce to the ContactList.
This solution has afforded us to ensure proper retry logic is implemented and data interoperability with Salesforce is preserved for Contact & Opportunity CRM "Screen-Pop" .
Below is a screenshot of the trigger, and I've attached sample data-actions in a zip file. Hope this helps . .
#ArchitectandDesign
#Outbound
#Routing(ACD/IVR)
------------------------------
Mark Pareja
Principal Voice Engineer, Archi-doer
------------------------------