We are having an issue with our new Task Routing setup. We are getting tasks properly routed to Finesse agents via Task Routing so that direction of flow is working. What isn't working is that Closed tasks by Finesse agents are not being removed from SocialMiner and RONA tasks are not being requeued to SocialMiner (again by Finesse). Both would indicate that the messaging flow from Finesse back to SocialMiner is not working (as the documentation says it is Finesse that reports both of these back to SocialMiner). Now I don't recall seeing any configuration where Finesse is given the SocialMiner info directly. Does anyone know what the messaging flow is for traffic from Finesse back to SocialMiner is and what parties are involved? Also what logs would be useful to check. We have confirmed that the Finesse AWDB user is properly configured as per the Cisco Task Routing section of the UCCE Features Guide. ... View more

Recently we have seen changes in how CallTypes are presented in Finesse 11.6 (the UCCX variant so far). I am just wondering if these changes were intended or are a newly introduced bug. I also understand that Finesse is basically passing through the CallType from ICM. We are seeing changes in how Outbound calls are reported. In version 10.6 if an agent placed an Outbound call to a queue we would see the CallType of "OUT" for all call state events (INITIATED, ALERTING and ACTIVE). With 11.6 we are seeing the CallType of "OUT" on the INITIATED call state event but "ACD_IN" for the call state events for (ALERTING and ACTIVE). Again this is for an Outbound call to a queue. So is it supposed to be reporting the CallType as "ACD_IN"? ... View more

Hi Denise. I have a question on transfers, callTypes and the corresponding event sequence. In the scenario where Agent1 receives an ACD call dialog #1 ("PREROUTE_ACD_IN") and transfers the call to Agent2 we normally see something like the following on Agent2. Sequence 1: ========== callType "CONSULT" dialog #2 (Agent1 to Agent2) callType "TRANSFER" dialog #1 (includes original caller, Agent1 drops off) DeleteDialog for dialog #2 Agent2 now talking to customer on dialog #1 But recently we have seen the following variation. Sequence 2: ========== callType "TRANSFER" dialog #2 (both Agents and original caller, Agent1 is dropping off) DeleteDialog for dialog #2 callType "OTHER_IN" dialog #1 (Agent2 and original caller) Agent2 now talking to customer on dialog #1 This event sequence is being seen on a 10.5.1 system. The first sequence we have previously seen on similar 10.5.1 systems but not on this particular system. My questions are: 1. Is it normal/expected for the customer to appear on the initial consult/transfer leg seen by Agent2? 2. Is it normal/expected for this call leg then to be deleted before the original call with customer is presented to Agent2? 3. Is it normal/expected for the original call when presented to Agent2 to have callType "OTHER_IN"? Thank you for any insight you can provide Denise. ... View more

How many simultaneous XMPP connections will Social Miner support for monitoring the status of task routing tasks? Also are there any API limits (e.g. calls/minute) if using API calls to monitor the status of task routing tasks? ... View more