I've been having all kinds of problems debugging my warm transfer UI. It's a seemingly endless list of crazy what-if scenarios, but at the root of it all is the fact that my code is misreading who is the agent, who is the customer, and who is the third party. Nailing that information down in a concrete, reliable, predictable way is something like alchemy: it's either dark sorcery or some kind of miracle. I would try to get into further detail, but every time I try, the text/code I type in here feels less like useful info and more like ranting. I don't want to do that. So I guess the best I can do is clarify the question a bit...
Originally, I tried to figure out who was the agent by purpose="agent". That didn't work because it's different for inbound vs. outbound calls. My current guess is going by the "userId" field; hopefully that is always present across object variations (the willy-nilly object structure makes it anyone's guess, lol).
Originally I tried to figure out who was the customer by purpose="customer" - same problem.
For identifying the third party, I went with the "destinationParticipantId" of some API call, I think the one that starts the transfer. Seems logical, but not always.
Of course if I transfer to another agent, the whole thing gets thrown out of whack on that person's account (cuz then userId points to the third party instead of the one who started the transfer)...
And I could go on. Bottom line, the object structure of these participants seems very random, haphazard, and not well-defined, so I'm playing Whack-A-Mole with these participant lists, trying to pin down who is who in a transfer. But I'm thinking, is there like, an object structure list or something with more information? There just seems to be so much assumed knowledge that you can't get from the lists of parameters/return values. I've been hack'n'guessing my way through this API for over a year now, and I still find myself scratching my head and wondering why things aren't what I thought they would be. And a lot of it stems from these object hierarchies, that don't seem to be documented anywhere (publicly). I don't know if I'm even asking this right, that's how confused I am right now.
Quick update to this; so I've kinda been writing my own docs on what fields are present in a "participant", and this has helped A LOT. There are still plenty of unknowns, and I'm still deep in this rabbit-hole, but there is light at the end of it. Here are a few highlights, in case it would help anyone else:
The participant who is the user will have a "userId" field that is equal to the user's Genesys ID (a GUID). So this can be used to identify which participant is the current user.
Each participant has about a half a dozen arrays-of-objects, each representing a different type of conversation ("calls", "chats", etc.). A lot of these are empty in my case, so I don't know if those objects follow any kind of consistent, predictable pattern or not... but I'm guessing not.
I don't recall the details off-hand (as I'm not in that part of the code atm), but somewhere in the object tree you can find details about the user's current connection state. So if it's "terminated", then obviously it's not one of the people that's still on. This means, a function could be written to get all connected participants, and it would be a matter of a simple for-loop just checking that field. And from there, a combination of "purpose" and "participantType", and maybe "startTime", could be used to figure out who is i.e. the third party in a 3-way warm transfer
Also, each participant has its own wrap-up settings. For the past few years, the way our team talks about "wrapping up the call", I always thought that wrap-up was done on the conversation (the call), despite the fact that Genesys wanted a participant ID for some unexplained reason. So what's cool is, I was able to update my program so that in a 3-way transfer, all participants who are users of my software can submit wrap-up info (a bug due to lack of information, but still a bug, and now a squashed one ).
So although I have yet to find much in the way of field-level docs, explaining what's what and why, I think this approach of writing my own docs will go a long way in predicting the unpredictable. Who knows? Things might even start to make... sense.
