Troubleshooting events not triggering

Triggers
1

I'm new to this part of the platform, but I thought I had this nailed down. My goal is to trigger a workflow whenever a caller abandons a call in queue. To do this, my approach was to configure a trigger on v2.detail.events.conversation.{id}.customer.end

So I have trigger as noted below, and the JSONPath validator does take this down to a list of the event names, which I then use to see if tAbandon exists.

In the workflow, I'm really only using Conversation ID as an Input Variable, and then I do the following:

  1. Get a participant data attribute contains SF_URLPop (Salesforce Case)
  2. Using that, query the Salesforce API to get additional data for that Case ID
  3. Using that response, update the Status of the Case to "Closed - In-Queue ABN"

In my Workflow, I have added a debug Reusable Task that appends a Participant Data attribute as the workflow progresses through the 3 steps above.

My issue is, the Salesforce Case isn't updated, and the participant data for debugging isn't populated either. This leads me to believe the trigger isn't firing at all, since I set participant data at all stages of the Workflow in all paths to properly log debugging info. Either that, or my JSONPath is not including the content expected, which is possible since the Genesys documentation has only a single example of this parameter in real-world use. Both Data Actions have tested successful when run manually via the Data Actions test screens.

Trigger

{
  "entities": [
    {
      "id": "80e339c4-5fd1-4a78-883a-512f32f57208",
      "name": "Update Salesforce Case When Call Abandons",
      "topicName": "v2.detail.events.conversation.{id}.customer.end",
      "target": {
        "type": "Workflow",
        "id": "277a824f-2581-48d1-a740-1f84268f6efe",
        "workflowTargetSettings": {
          "dataFormat": "TopLevelPrimitives"
        }
      },
      "version": 1,
      "enabled": true,
      "matchCriteria": [
        {
          "jsonPath": "mediaType",
          "operator": "equals",
          "value": "VOICE"
        },
        {
          "jsonPath": "$..participants..metrics..name",
          "operator": "Contains",
          "value": "tAbandon"
        }
      ],
      "description": "When a call abandons, change the Case Status in Salesforce to \"Closed - In-Queue ABN\"",
      "selfUri": "/api/v2/processautomation/triggers/80e339c4-5fd1-4a78-883a-512f32f57208"
    }
  ]
}

I've checked to ensure the trigger is set to enabled via the API (did that on creation) and that the input variable on the Workflow (which is published) is actually set as a Flow Input for conversationId to pick that up from the trigger.

JSONPath $..participants..metrics..name returns this when run on a conversation JSON returns this array

[
  "tContacting",
  "tDialing",
  "tHandle",
  "tTalk",
  "tTalkComplete",
  "nFlow",
  "tIvr",
  "tFlow",
  "tFlowExit",
  "nOffered",
  "tAbandon",
  "tAcd"
]
2

Leaving original as-is so others can learn from my mistakes. The JSONPath part is kind of a red herring for inbound calls because the structure of those events seems to be completely flat anyways. My issue was that I was trying to take the content of an conversation's JSON, not an Event's JSON, and they are quite different. Removing the second JSONPath does indeed get the trigger to fire the workflow.

So in order to achieve my goal, I likely have to fire this on every Customer End event and then in the workflow figure out if that conversation was an abandon or not (somehow, TBD on what I can do with native Architect tooling vs. custom API and JSON parsing).

3

Hi there,

You can also use: v2.detail.events.conversation.3771bab0-b16e-448c-b116-67be1b3828bc.acd.end, which will give you the "acd outcome" value in the schema.. I might recommend you use this topic instead, because you can filter by interactins with an acd outcome of ABANDON.

Would that work for you?

{
"eventTime": 1689629412123,
"conversationId": "3771bab0-b16e-448c-b116-67be1b3828bc",
"participantId": "5cedb22f-8c73-4f00-9181-26359821827c",
"sessionId": "1d7671ff-0838-4756-98e1-ba9826369306",
"disconnectType": "PEER",
"mediaType": "VOICE",
"provider": "Edge",
"direction": "INBOUND",
"ani": "tel:+1xx",
"dnis": "tel:+1xx",
"queueId": "9082d07b-40ac-47ae-9b5e-c76dd9768a12",
"divisionId": "9cb31c55-a498-4bbe-a844-34a813d9b906",
"acdOutcome": "ABANDON",
"usedRouting": "UNKNOWN",
"routingPriority": 0,
"connectedDurationMs": 60917,
"conversationExternalContactIds": [
"7302f1c5-640b-4ed3-b6d8-ffc0f09e14b2"
]
}

1 Like
4

Hi Peter,
This sounds more logical for this use case, yes. Initial testing of the abandon use case work as expected just by changing that match criteria to the below. I need to battle test it a bit more to make sure it only marks the expected cases as abandoned and hits the different paths in the workflow, but I very much appreciate the nudge towards the other topic for this one.

{
  "id": "9f63a524-ce7d-4346-a495-2696a8fa0142",
  "name": "Update Salesforce Case When Call Abandons",
  "topicName": "v2.detail.events.conversation.{id}.acd.end",
  "target": {
    "type": "Workflow",
    "id": "277a824f-2581-48d1-a740-1f84268f6efe",
    "workflowTargetSettings": {
      "dataFormat": "TopLevelPrimitives"
    }
  },
  "version": 1,
  "enabled": true,
  "matchCriteria": [
    {
      "jsonPath": "mediaType",
      "operator": "Equal",
      "value": "VOICE"
    },
    {
      "jsonPath": "direction",
      "operator": "Equal",
      "value": "INBOUND"
    },
    {
      "jsonPath": "acdOutcome",
      "operator": "Equal",
      "value": "ABANDON"
    }
  ],
  "description": "When a call abandons, change the Case Status in Salesforce to \"Closed - In-Queue ABN\"",
  "selfUri": "/api/v2/processautomation/triggers/9f63a524-ce7d-4346-a495-2696a8fa0142"
}
1 Like
5

Peter's solution above was what did it. I wish Genesys published real example event payloads to make this easier. Schema documentation is nice, but real-world data examples are usually always better to get started with.

6

FWIW event payloads vary based on circumstances, so most examples would be invalid for some portion of use cases. You can always use the notification tool to test events and see the actual payloads without having to write any code. The schemas themselves are documented here, as well as available in raw form via the API.

7

Oh wow, thanks Tim. I didn't know about that tool, and that should definitely help in vetting event payloads for my trigger development. Now that I have my "abandoned in queue" one built, I get to move on to the "when interaction ends" logic. that one will be more fun, since there isn't a clear-cut event for that one. Probably looking at tieing it to Wrap-Up or Agent Disconnect.

8

Agent events are likely misleading for this purpose since that can happen multiple times per conversation. When an agent transfers a call back to queue, for example, this event will be emitted but the customer will still have further action ahead of them.

There isn't a specific event for conversation end, but depending on exactly what you need to measure for your business purpose, the customer end event might be it. That is based on the customer's segment only, so it's possible that the conversation is still ongoing for another participant. To identify the end of the conversation itself, you would need to monitor the conversation events directly and watch for the first event that has an end date for the conversation. There are reasons you may receive additional notifications after the conversation has ended, which is why it's important that your app have state to be able to identify the first event with an end date.

9

For this specific case, I want to write the conversationId to a CRM data field. It actually doesn't matter when I do it, but I want to ensure I'm only doing/attempting it once for the conversation. I could actually do it on ACD start, actually, and achieve the desired result. The thing I need to avoid is a race condition where Genesys is writing the CRM record at the same time the agent is attempting to do an edit. So it might actually be better to do that on ACD start than at the end of the coinversation (when an agent could be writing notes during ACW).

10

ACD start can still happen multiple times if the customer is re-queued. I would expect v2.detail.events.conversation.{id}.customer.start might be a good fit as it should fire very early on in the conversation and will only happen once.

11

I can't use that one because I won't have the CRM record ID when that event fires. I get that ID from the caller based on them entering a Case number in the IVR, or when the IVR creates a Case for them if they don't supply one. I'm OK with acd.start firing multiple times, since it'll only be a couple at most on average, and I can just design the workflow to only do CRM updates when it needs to, vs. just blindly pushing them (query record first, use Decision logic to determine if update is needed).

12

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