Genesys Cloud - Main

 View Only

Discussion Thread View
  • 1.  Accessing Participant Data from Architect

    Posted 09-15-2023 16:50


    Other than using a Data Action (with a lot of subsequent processing!) does anyone know how to access a Participant Data Attribute, from a flow, for the non-current participant?

    Here is the situation...

    I have a customer that is using an external bot service to do some initial customer authentication. The way it works is that the call is transferred to the service using a SIP tie line / trunk and then returned by that service once the authentication is complete. This is achieved by the bot transferring the call back on the original DNIS, with the retrieved data attached as Participant Data Attributes. (I have yet to figure out how THAT is achieved, but that's a different story!) This means that when a call arrives in the flow, we don't initially know if the call is new and needs to go to the bot, or returning from the bot. This is solved by looking for the Participant Data Attributes coming back. No data means send it to the bot, data is there means it's coming back and can be processed.

    With me so far?

    OK, this works fine. Usually.

    The problem comes when the call originates from within the ORG. (So either a test call placed internally or, more importantly, a transfer.) What seems to be happening is that an additional Participant gets created and the returning Participant Data is attached to the wrong one, so is not seen! I believe this has probably got something to do with Genesys not "Tomboning" these calls and thus the call being treated differently (this, incidentally, is why internal calls can't currently be recorded.)

    This is what happens:

    Call is placed by the User, a Participant (named as the user) is created and all Participant Data Attributes Set, or Retrieved by the Flow using the standard tools is attached to that participant. The call goes out to the bot and the authentication data is collected before the call is returned. The collected data is also attached to the initial Participant, however a new Participant is created (named after the bot's tie line) and it is THIS participant that the flow is accessing when the standard tools are used. As a result, the call appears to have not been to the bot (since no returning data is detected) and it is sent back to the bot.

    So, my question is, how can I look for Participant Data Attributes being set across all participants in the call, from the Flow? I need to scan for an Attribute of say "ReturnValue" from any participant, not just the current one.

    I hope that makes sense (in some way!). I figured I could potentially use a Data Action to retrieve all the Participant Data for the call and then iterate through looking for the Attribute in question, but I had hoped there would be an easier way. (Note: I don't think I can rely on the data always being attached to Participant[0] either....)



    Paul Simpson
    Eventus Solutions Group

  • 2.  RE: Accessing Participant Data from Architect

    Posted 09-24-2023 00:03

    First, I would have the outside bot service use a SIPRefer instead of the transfer back in so that it remains in the same conversationId as the original call.  Second, I would have them use an identifier in UUIData that can be read and then use an API to look up the values, unless you can fit them all in the UUIData field.  The support of x-headers will make this part easier and that will be here in say a month or so. Now, if the SIPRefer is not going to be possible, then you send them UUIData with a conversationID that needs to come back to you and you can use the conversations API to get the attributes from the original call and attach to the new one.

    Robert Wakefield-Carl
    ttec Digital
    Sr. Director - Innovation Architects

  • 3.  RE: Accessing Participant Data from Architect

    Posted 09-25-2023 12:44

    Thanks, Robert.

    I will obviously explore options like you suggest, but I fear that the bot services is a fixed entity, so modifications to the way it works are likely to either not be possible, or have a long implementation time.

    I need to clarify a couple of things, as your final suggestion is looking like it may be along the right lines..

    Firstly, the issue we are trying to solve only affects a small percentage of calls - namely those that originate inside the ORG (and so do not initially arrive on an external trunk.)

    Secondly, all the data is part of the same conversation, but in the cases I'm trying to solve, it's attached to a different participant to the one Architect is accessing with the standard Get / Set Participant Data operations.

    If there is a way, similar to what you suggest, to take all the Data associated with all participants and either copy or move it to the current one, that would solve the issue, but I am not sure how to do that with Data Actions from within Architect only. (I could probably do it with an external middleware service, but that's not an option at the moment.) You have any ideas on how to do it?

    Alternatively, my thought was to create a Common Module that grabbed the conversation details and then iterated through all the Participants, looking at the Data on each in turn, and then either returning just the data being searched for, or a list of key-value pairs representing all the data, which the calling Flow could then access. My advanced Architect data-processing foo is somewhat lacking, so if you have any thoughts on how that could be achieved, I'd be grateful!

    Paul Simpson
    Eventus Solutions Group

  • 4.  RE: Accessing Participant Data from Architect
    Best Answer

    Posted 10-09-2023 13:10

    OK, for anyone else who stumbles across this, here is the fix:
    Use the Data Action I mentioned, but in the translationMap, you can configure it to grab an array of a particular Attribute from all Participants, like this:
    "$.participants[*].attributes.<attribute name>"
    In your Output Contract, you need to specify a String Array for this. Then, in Architect, you get the array and test the Count of it to verify if a value was returned at all. (In my case, there is only ever a maximum of one.) The end result is getting a Participant Data value regardless of Participant.
    Many thanks to @Craig Stevenson for putting me on the right path!

    Paul Simpson
    Eventus Solutions Group

Need Help finding something?

Check out the Genesys Knowledge Network - your all-in-one access point for Genesys resources