Hi, I did an analysis of the logs you provided and came to this conclusion: In the scenario where there are no agents available (#1) and call variable 3 gets updated correctly, Caller 1416 -> 1111 -> VG 2900: Original callId=16800318, callVariable3=CC_Code_1_1_PQ, callType=PREROUTE_ACD_IN Agent 1001 answers the call. Agent 1001 does a single step transfer to RP 2752 with no agents available: Consult callId=2130706446, callVariable3=CC_Code_1_2_PQ All calls are dropped for Agent 1001 due to the transfer Agent 1002 goes READY Agent 1002 gets a call. callId=16800319, callVariable3=CC_Code_1_2_PQ, callType=PREROUTE_ACD_IN If you notice, when Agent 1002 goes READY and gets the call with the updated call variable 3, the call id is different than the original and consult call, and the callType is PREROUTE_ACD_IN instead of TRANSFER. It seems like UCCE treats the call to Agent 1002 as a queued call and loses the transfer details. In the scenario where Agent 1002 is available (#2) and call variable 3 doesn't get updated correctly, Agent 1002 goes READY Caller 1416 -> 111 -> VG 2900: callId=16800274, callVariable3=CC_Code_1_3_PQ, callType=PREROUTE_ACD_IN Agent 1001 answers the call. Agent 1001 does a single step transfer to RP 2752 and agent 1002 is available. Consult callId=2130706446, callType=AGENT_INSIDE Original callId=16800274 has callVariable3=CC_Code_1_3_PQ Consult callId=2130706446 has callVariable3=CC_Code_1_2_PQ After the transfer is complete, the original call with id of 16800274 survives. As a result, all of the call variables from that call survives ( callVariable3=CC_Code_1_3_PQ) , callType=TRANSFER If you notice, in this situation, the consult call is the one that gets its call variable 3 updated. Since the original call (almost) always survives, the updated call variable 3 gets lost. UCCE is sending Finesse the events like this, so Finesse is just reading in these events and processing it. There isn't anything Finesse can do in this situation. If it is a problem for you, you have to chase the issue with the UCCE/PCCE team. I have attached my notes (copies of log snippets from the webservices logs) to come to this conclusion. Thanx, Denise ... View more

Hi, Take a look at the jquery documentation about unload: https://api.jquery.com/unload/ According to that documentation, The exact handling of the unload event has varied from version to version of browsers. For example, some versions of Firefox trigger the event when a link is followed, but not when the window is closed. I put the code you pasted above into the gadget's init (SampleGadget*.js). When I added a link to the gadget (make sure the link is https to avoid the mixed-mode browser error) and followed it, the unload is triggered. If I closed the window, it didn't trigger the unload. Thanx, Denise ... View more

Hi, Please take a look at the Subscription management section of the Finesse developer guide on how to subscribe to notifications. The Resources section of the guide explains what triggers an event for that particular node. I hope this helps. Thanx, Denise ... View more

hi, Since you get the CUIC login screen, the gadget is able to load the correct URL. I am not an expert in CUIC, but I believe that permalink should be able to be used via the browser itself? If so, are you able to log in on the browser? To be sure that it is the link and not the gadget, please provide the client logs. 1) click the "Send Error Report" link on the lower right to send the client logs to the Finesse server. 2) Then grab the logs using the URL: https:// <FQDN>:8445/finesse/logs/clientlogs. Thanx, Denise ... View more