GET Participant data node in In-queue call flow failing to read attributes set via API

Use case:
Agent makes an outbound call on behalf of a queue ( say 'OB queue' ), which gets transferred to another queue ( Say 'survey Transfer Queue' ) upon disconnect by the agent ( using SDK ) triggering a Survey flow attached to the in-queue flow of the 'survey transfer queue'.

Challenge :The challenge was to play the prompts in different language. As per this earlier post, we were successful in setting up the language code in an attribute when the first leg of the call is made on behalf of 'OB queue' .

Issue: However, when we use the 'Get participant' data step in the In-queue flow of "survey transfer queue', the flow is failing to read these attributes. however, If we use the conversation api end point to query, we see the attribute listed. Is there any reason as why the "Get participant data" node fails to show these attributes which it should have inherited from the parent queue during transfer.

p.s.

This works well in case of proper Inbound to ACD queue and then transferring to the survey queue, we are able to see the attributes set in the IVR, but doesn't work when we write the attributes to the first queue via API.

Unable to find the reason, we are planning to create a PureCloud data action using conversation API endpoint and then try and read the attributes.

The attribute ("participant data") may be written to a participant the flow is not checking. Have you:

  1. Tried adding the attribute to a different participant?
  2. Ensure you're adding the attribute to the conversation before the in-queue flow is invoked?

An alternative is a Data Action to get the attribute from the conversation. This action looks at all participants and returns the first instance of an attribute with the matching name.Get-conversation-attribute-by-conversation-id.json (1.2 KB)

Note the action is specific for an attribute named in the translation map - you'd need to update "key" to match your attribute name.

  "translationMap": {
    "value": "$..key"
  }

Thanks for the quick response @Smith_Rj.

  1. We will try and do this.
  2. This is for sure as the outbound call is triggered via our own UI which places the call on behalf of the queue. The attributes are written at this stage and then the agent hangs-up the call which transfers the call to the second queue ( no members ) which invokes the In-queue flow to play the survey questions.

Here is an actual sample_call.json (8.0 KB)
call data ( few values modified deliberately ) of a test call where we can see the attributes at x.participants[0].attributes

The get participant data action doesn't read it and unable to get the custom data action right, which I am trying, including the one you just shared to fetch the values ( getting 404s all the time )

You are hitting a scripting feature. Script output variables cannot be retrieved in Architect scripts

See https://help.mypurecloud.com/articles/script-input-output-variables/

  • If only output is true, then the script attaches the data to the agent participant.
  • If both input and output are true, then the script attaches the data to the participant it found the data on, which in most cases is the customer participant. Otherwise, the default location is the agent participant.For example, if the data comes from Architect through an input variable, then Architect places the variable data on the customer participant, and future updates to that variable override the value on the customer participant.
1 Like

Thanks for the response @mikehardie , this is not related to script but we are trying to read attributes of the active conversation from the in-queue flow via architect.

@Smith_Rj Was able to read the attributes by creating a custom data action in one of our orgs. Apparently ran into a weird OAuth issue in our major org, have raised a case with support. Thank you for your inputs.

1 Like

That's great to hear, I'm glad it's working for you :+1:

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