UCCX Call Back

[mightyking]

Hi Expert,

I have a callback system that works fine. Now I need to work with two queues at once. We need to take into account the language in which the call was received and make the callback with the appropriate language. The language options are English and French.

I have the main script where I use a subflow to send the call to the callback script. In the subflow I send the CSQ and the language to the callback script. So far everything works fine. The problem starts when the callback script makes a call to a subscript for the callback call to be queued.  I am not able to send the CSQ and the language to the subscript where the call is queued. I would appreciate if someone could shed some light on this and help resolve this issue.

Thanks,

MK

[Elliot Dierksen]

Are you attempting to use 'triggering contact' in the sub-flow? My experience has been that does not work. You will need to pass the the triggering contact to the sub-flow as a parameter. I prefer to use a variable like 'WorkingContact' that I populate with either triggering contact or the parameter based on how the script is invoked.

[mightyking]

Hi Elliot,

Thank you for replying.

Would you happen to have an example of the solution to share?

Thanks,

MK

[Elliot Dierksen · Accepted solution]

The attached screen shot is a common code block that I have refined over the years. The idea behind this block is that it should work regardless of how it was invoked. That could be as a JTAPI trigger (normal), a call sub-flow (less common), or even a trigger application (unusual). I won't go into it here, but there is some baggage with trigger application so I almost never use that.

The Get Trigger Info step is the CCX version of "Who summons me?". A return value of "Step Trigger" means is was called as a sub-flow or by trigger application. I don't recall clearly as some of this code is over a decade old. It works well enough that I don't recall the last time I had to change it.

In the Step Trigger block, we get the contact via the Get Trigger Info step. For the JTAPI trigger block, you could use Triggering Contact but I don't. I think that is to deal with being invoked via trigger application, but I am not sure. The Get Call Contact Info step retrieves the contact in either case.

You can disregard the ArrivalType block. That was based on a customer request that direct calls to the trigger would overflow to an external service, but calls that were forwarded to the trigger should not go to the external service.

The last block deals with creating a session so variables can stay with the caller for the duration of the call, even if they are passed between different scripts. ImplementationID is the CUCM call ID. This stays the same for the duration of the call. I use the Call ID (GUID) as the session key. I check to see if it already exists which would mean the caller has interacted with a previous script. The only session variable I have in there currently is the Language selection. I loathe having to select languages over and over again as a call is passed from one application to another. This way it stays in effect once the caller selects a value, assuming all the application have the ability to do multi-lingual. The ChildAppFlag is used further on where the caller would be prompted for a language selection, so the application knows not to prompt the caller again.

I suppose I could have made a common script to neatly encapsulate a bunch of this and call it in a sub-flow, but that might have complicated the trigger type detection. I (sadly) don't get to do much script development these days, but I do have ideas on how to refine it should the chance arise.

Edit: I realized it is casually implied in the comments of the script, but I wanted to explicitly state that WorkingContact is defined as a Contact type variable that is a parameter.

[Anthony Holloway · Accepted solution]

You know the Contact you create and use on the Place Call step?  This contact is the same contact as --Triggering Contact-- on the script which does the queuing.  Why is that important?  Well, because, in the script which does the Place Call step, you can use Set Enterprise Contact Info, to store information about the caller, such as CSQ name and Language, as Enterprise Data, and then in the receiving script, you can use Get Enterprise Contact Info, to read it.  Hope that helps.

[mightyking]

Hello again guys,

My Callback script is working now as expected. The only issue is that the CUIC report shows the Callback as an abondant call. Is this a normal behaviour or I am mising some configurations?

TEST_2iem_Chance_Fr is the main queue where the callers are waiting and SK_JEL_CALLBACK_Fr is the Callback queque.

Thanks,

MK