Genesys Cloud - Developer Community!

 View Only

Sign Up

  • 1.  Data Action Failure on Integer Collection

    Posted yesterday

    Hi,

    Has anyone had issues with using a POST API (/api/v2/analytics/flows/observations/query/) from within a inbound call flow. I'm attempting to understand flow metrics and based on the result route differently.

    I've used the above API and in my data action is works perfectly, but seeing a failure when running the data action in a architect flow. If I remove the variable assigned to the 'oflow' 'count' then the data action does not fail, but if used it fails all the time and I'm thinking it's to do with the output being a integer collection.

    Any ideas ?

    Regards, 


    #Architect
    #DataActions

    ------------------------------
    Neil Jones
    Voice Comms Lead
    Awaze Uk
    neil.jones@awaze.com
    ------------------------------


  • 2.  RE: Data Action Failure on Integer Collection

    Posted yesterday

    Hi Neil,

    From what I can see and understand from the screenshots, it doesn't look like the integer value itself is the issue. The Data Action test succeeds, and the count value for the oFlow metric is valid.

    It looks more like a response structure / collection issue. The Analytics API response includes nested arrays under results and data, so fields like metric and stats.count are part of a collection. If Architect is trying to map those directly into single-value variables, that can fail even though the API response itself is fine.

    If you keep the current response structure, you may need to use GetAt() or similar collection handling in Architect to access the first item in those arrays. The cleaner option, though, would be to flatten the Data Action response in the success template and only return the exact fields you need.

    For example, instead of returning the full nested response structure, the success template could return something like:

    {
      "flowId": "${rawResult.results[0].group.flowId}",
      "mediaType": "${rawResult.results[0].group.mediaType}",
      "metric": "${rawResult.results[0].data[0].metric}",
      "count": ${rawResult.results[0].data[0].stats.count}
    }

    If you go that route, I would also update the output contract to match the flattened response, for example

    • flowId = string
    • mediaType = string
    • metric = string
    • count = integer

    That should make the Architect mapping much cleaner and more reliable.

    Hope this helps and hopefully someone from community might add more to this.

     



    ------------------------------
    Phaneendra
    Technical Solutions Consultant
    ------------------------------

    Original Message


Related Content