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
------------------------------
Original Message:
Sent: 09-24-2023 00:02
From: Robert Wakefield-Carl
Subject: Accessing Participant Data from Architect
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
Robert.WC@ttecdigital.com
https://www.ttecDigital.com
https://RobertWC.Blogspot.com
Original Message:
Sent: 09-15-2023 16:50
From: Paul Simpson
Subject: Accessing Participant Data from Architect
Hi,
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....)
Thoughts?
#Routing(ACD/IVR)
------------------------------
Paul Simpson
Eventus Solutions Group
------------------------------