Translation map for complex data action result!

Hi guys,

I'm struggling to get the data I want from a data action.
I'm using /api/v2/analytics/conversations/details/query to get the active conversations for a user - and also managed to return an array of the desired conversation IDs already - which is the state of the attached version.
(ok - or not, because as a new user I'm not allowed to upload attachments obviously... :disappointed_relieved:)

Now I want to add additional properties to the array - making it an array of objects instead of strings.
The output contract I already prepared would be like this:

{
"type": "object",
"properties": {
"conversationData": {
"type": "array",
"items": {
"title" : "conversation",
"type" : "object",
"properties" : {
"conversationId" : { "type" : "string" },
"participantId" : { "type" : "string" },
"communicationId" : { "type" : "string" }
},
"additionalProperties": true
}
}
},
"additionalProperties": true
}

The thing I'm struggling with now is the translation map. My goal is to add the following data for each conversation (id) returned:

  • The participant ID of the user ID that I passed to the data action in the body template: ${input.UserId}
    Is it even possible to reference the input variables in the translation map?
  • The session ID (=communicationId") from that participant.

Any help cosntructing the translation map would be highly appreciated.

Thanks

So let me just post the exported action as text:

{
"name": "Get Active Conversations by User - Exported 2024-04-19 @ 16:21",
"integrationType": "purecloud-data-actions",
"actionType": "custom",
"config": {
"request": {
"requestUrlTemplate": "/api/v2/analytics/conversations/details/query",
"requestType": "POST",
"headers": {},
"requestTemplate": "{\n "interval": "${input.IntervalStart}/${input.IntervalEnd}",\n "order": "desc",\n "orderBy": "conversationStart",\n "paging": {\n "pageSize": 25,\n "pageNumber": 1\n },\n "segmentFilters": [\n {\n "type": "and",\n "predicates": [\n {\n "type": "dimension",\n "dimension": "userId",\n "operator": "matches",\n "value": "${input.UserId}"\n },\n {\n "type": "dimension",\n "dimension": "mediaType",\n "operator": "matches",\n "value": "email"\n },\n {\n "type": "dimension",\n "dimension": "direction",\n "operator": "matches",\n "value": "inbound"\n },\n {\n "type": "dimension",\n "dimension": "segmentType",\n "operator": "matches",\n "value": "interact"\n },\n {\n "type": "dimension",\n "dimension": "segmentEnd",\n "operator": "notExists",\n "value": null\n }\n ]\n }\n ],\n "conversationFilters": [\n {\n "type": "or",\n "predicates": [\n {\n "type": "dimension",\n "dimension": "conversationEnd",\n "operator": "notExists",\n "value": null\n }\n ]\n }\n ]\n}"
},
"response": {
"translationMap": {
"conversationIds": "$.conversations[*].conversationId"
},
"translationMapDefaults": {},
"successTemplate": "{"conversationIds" : ${conversationIds}}"
}
},
"contract": {
"input": {
"inputSchema": {
"type": "object",
"properties": {
"IntervalStart": {
"type": "string"
},
"IntervalEnd": {
"type": "string"
},
"UserId": {
"type": "string"
}
},
"additionalProperties": true
}
},
"output": {
"successSchema": {
"type": "object",
"properties": {
"conversationIds": {
"type": "array",
"items": {
"title": "id",
"type": "string"
}
}
},
"additionalProperties": true
}
}
},
"secure": false
}

It is currently not possible to use an input parameter in your translation map. You can vote for this idea here:
https://genesyscloud.ideas.aha.io/ideas/OTB-I-224

You might want to consider gathering this data in one data action, and then processing it with a second data action, like an AWS lambda or a function lambda (beta signup here: Microsoft Forms. )

--Jason

Hi Jason,

Thanks for the reply - this is unfortunately about the result I was expecting, but I alread voted and it's good to know the idea is already quite popular.

I did solve the problem using a different endpoint - allowing an easier request.
Using another data action was something I rther tried to avoid, as assumably every additional data action increases the performance lod generated by this - which in confunction with a frequently executed trigger seemed a questionable idea.

Cheers
Michael