Remapping "not found" to avoid tagging as an error

[Vikki_Papesh]

Greetings. I have a data action that looks for an ANI match against CRM stripping tel:, which yields an E.164 formatted number that will resolve to a record in CRM. Very frequently, the caller calls from a number that is not the primary contact number in the CRM account, which is and will remain the only number we check against.

Currently, when a number is not found in CRM, it reports as "error" and takes the Call Data Action failure path. I'd like to convert these "no match" from failure to some sort of "not found" success so that we can more accurately see our data action performance.

Can this be done with success template or translation map?

[stevennichols]

@Vikki_Papesh

Currently, when a number is not found in CRM, it reports as "error" and takes the Call Data Action failure path. I'd like to convert these "no match" from failure to some sort of "not found" success so that we can more accurately see our data action performance.

Test the output of the data action in from the SETUP tab in the Data action. See what is returned when you test the Data Action. You can best see the return value in the 7. Execute Operation.

Keep in mind that if the CRM is responding with a 404 not found, Genesys will translate that to a failed data action call. I've also seen type mismatches happen on different responses before as well. Good luck.

[Vikki_Papesh]

The data action works fine if I put in a number that exists in CRM, it executes with no issues. However, a number that is not in CRM returns:

{
  "message": "No results were found.",
  "code": "no.results",
  "status": 400,
  "messageParams": {},
  "contextId": "1234xxxx-yyyy-aaaa-bbbb-1234567890ab",
  "details": [
    {
      "errorCode": "ACTION.PROCESSING"
    }
  ],
  "errors": []
}

[Oscar_T]

I think the issue is that Genesys considers all non 2xx codes to be "failures" which is kinda weird

[tim.smith]

Per the HTTP status code spec, only 2xx errors are successful; all other codes are something other than success. Data actions aren't meant to be a programming environment; they're meant as a data lookup tool that either returns data or doesn't. If you need to add additional handling logic beyond what data actions and architect provide, using a middleware application is the preferred approach. That application should encapsulate the 3rd party request and the additional logic you need to build around it. It can be built to return a response that the data action can always use.