I have a Workflow created to fire off based on the following trigger:
{
"entities": [
{
"id": "{TriggerId}",
"name": "Post-WrapUp",
"topicName": "v2.detail.events.conversation.{id}.wrapup",
"target": {
"type": "Workflow",
"id": "{WorkflowId}"
},
"version": 1,
"enabled": true,
"matchCriteria": [],
"description": "Log call data when an ACD call has been wrapped up",
"selfUri": "/api/v2/processautomation/triggers/{Id}"
}
]
}
I have included the conversationId as an Input to the Workflow so I can attach an External Tag to the conversation. It is the very first step in the Flow, and it is not being invoked by the trigger from what I can see. I thought I possibly wasn't getting the conversationId as expected, but even when I hard-code the "Set ExternalTag" conversationId, it still doesn't fire. I have ALL rights required in the OAuth Client for this Genesys Cloud Data Action as well. I can also manually run the Data Action and it works as expected, so it sems that the Workflow isn't even getting invoked.
If you are trying to trigger your workflow when a Contact Center Agent sets the wrapup code and completes after call work, the topicName you are using is not the right one.
You should use 'v2.detail.events.conversation.{id}.acw' instead.
See this recent answer on another post
v2.detail.events.conversation.{id}.acw
This topic pushes wrap up information set by an agent at the completion of after call work.
v2.detail.events.conversation.{id}.wrapup
This topic pushes wrap up information set by system IVRs or other API wrap up events not set by an agent.
I actually do have 1 more question regarding this topic. Can this Trigger be fired off more than once for 1 conversation if the call went to a single queue, a single agent, and that agent performing ACW? I assume if it was transferred there may be additional triggers fired off here. I am testing with a call going to a Queue, disconnecting after about 30 seconds, then completing ACW (Notes and Wrapup), and a Middleware API we are calling in the triggered workflow is somehow being called twice.
I am putting in additional points of failure to track this down, and doing the same with the Middleware API, but just curious if anyone knows the answer to this based on the scenario I described above.