UCCX Select Resource and Connect steps query

[James Hawkins]

Hi,

In the CCX step reference guide there is a warning which states "Never insert a Goto step in the middle of a Select Resource step flow. (Doing so can cause an active agent to enter a Reserved state that can only be exited by logging out of the system.)"

I am getting some agent stuck in reserved issues with a script that I have written and I am wondering whether I have fallen foul of this issue.

In my script the Select Resource step has Connect set to No

The script then has a Set step that does some calculations to work out how how the caller queued for followed by a Set Enterprise Call Info step which passes the queuing time and some other stuff through to be presented in Finesse.

I then have a Connect step and under the Failed branch I use a Goto step to send the call back to the queue.

Is this setup ok? - I have also tried dequeuing the call, increasing the priority then using a Goto to queue it but see the same issues.

What is the best practice for the Connect > Failed branch?

[Sean Lynch]

Unfortunately, YES you are creating your problem.  The Failed branch should GOTO (or go back to) the SELECT Resource step so the system processes can select another resource--and if another resource is NOT AVAILABLE, then the system can process the contact by sending it to the QUEUING branch:

Hope this helps.

-Sean

[James Hawkins]

Sean,

Thank you for responding to my query.I will test this and see if it resolves the issue.

Do you know of anywhere that this recommendation is shown in official Cisco documentation? - I have had someone else look at my script who thinks that the dequeue, increase priority then requeue is a valid option. TBH I prefer your option as it seems simpler.

Thanks

James

[Sean Lynch]

Yes, this is discussed in the Cisco official scripting development guides--where I learned it.  If I have some time, I'll try and find the exact reference, and post it.

-Sean

[Sean Lynch · Accepted solution]

Here are the links I mentioned.

The following explain the operational parameters for the "Select Resource" and "Connect" steps and branches:

https://developer.cisco.com/docs/contact-center-express/#!select-resource-step/select-resource-step

https://developer.cisco.com/docs/contact-center-express/#!connect-step/connect-step

Example scripts in script_repository\script_repository_902\ (select the link all the way at the bottom -- it's a .zip file containing many useful sample scripting examples) at:

https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-express/products-implementation-design-guides-list.html

The sample scripts in the script repository show examples of how to use the "Select Resource" step with the Connect option set to "No" and the Failed branch with the "Go To" step.  Review the scripts in the "release3" folder; script "BaseLineMesageCallback.aef" as an example...

This is how I found this, and started using it...  I also use this method for advanced resource selection (Agent and CSQ based...).

Sincerely,

Sean

[James Hawkins]

Thanks Sean - really useful info.

[Anthony Holloway · Accepted solution]

"...The Failed branch should GOTO (or go back to) the SELECT Resource step so the system processes can select another resource..."

Actually, that's not accurate. The Failed branch of the Connect step does not execute any steps at all, provided, there is at least one more ready resource who can be reserved. In which case, the Select Resource step becomes the active step in the script, and your Failed branch steps never execute. I'll see if I can put up evidence online about this, because it's come up a few times now, and I'd rather just show people, than keep explaining it. Here is a video showing it in action: https://youtu.be/kwEVBkka_Mo

In the meantime here's a screenshot of a sample script:

And the logs showing that the first Agent where we failed to connect to them, both:

1. Never executed the step inside of the Failed branch
2. Didn't need a Goto step to help it back to the Select Resource step (the interruption handler did that for us).

Then the logs show that the second Agent we failed to connect to, which also happened to be the last Agent available in that moment, did execute the step inside the failed branch.  In which case, what you really want in that step is to go into the queue loop you've created for yourself, and not back to the Select Resource step.

13:16:25.055: Execute step of Task 32000615282 : Start
13:16:26.652: Execute step of Task 32000615282 : Accept (--Triggering Contact--)
13:16:27.319: Execute step of Task 32000615282 : Select Resource (--Triggering Contact-- from "QueueAlways")
13:16:30.851: Execute step of Task 32000615282 : Connect (--Triggering Contact-- to selected_resource)
13:16:49.412: Execute step of Task 32000615282 : Interruption Handler: Select Resource (--Triggering Contact-- from "QueueAlways")
13:16:53.034: Execute step of Task 32000615282 : Connect (--Triggering Contact-- to selected_resource)
13:17:04.770: Execute step of Task 32000615282 : Set did_this_get_set_to_true = true
13:17:07.964: Execute step of Task 32000615282 : End

PS To get script steps executed from logs, you can follow my steps here.

Try it for yourself, it's pretty obvious what happens during a reactive debug.  The step inside the failed branch will be highlighted in red, post the first failure, but if you've ever reactive debugged a script, you'll know that the step has not yet executed when it's red, it only executes after you step over it.  In which case, the next red step will be the Select Resource step.  Again, I'll see if I can make a short video for evidence of this.

[Sean Lynch]

...as I said in my earlier post, sample scripts in the Cisco repository demonstrate this method--consistently, on multiple scripts. Perhaps this is a best practice?  Maybe.  Maybe not.  I didn't publish any of the scripts in the repository.  I borrow from them liberally, though.  ;-)

They do not ever demonstrate using a "Go To" step to a label in the event of a "Connect" step "failed" branch outcome. 

I do not think a new "Resource Select" process will happen correctly if this is done.  Just because the script allows the path of the contact to "jump to/go to" a different place in the flow--I don't think it will properly register with the resource selecting mechanisms in the program that cause it to drop down into the queue branch or selected branches by design.  The goal is to get the contact connected to a resource; queued if none are available.  Does this make any sense?  Putting a "Go To" step in the failed branch of the "Connect" step and dropping it in the "Queue" branch of the "Select Resource" step, to me, is illogical.

I haven't done this, but I may try it in my lab just to see what happens -- <reserved>...  

YMMV

-Sean

[Anthony Holloway]

Actually you were pretty blunt, telling the OP they were doing it wrong and causing their own problem, and that's false.

Also, there is a lot wrong with Cisco's scripts, and the documentation of the scripts/steps.

This is an open invitation for Cisco to reach out to me. I can fix all of the sample scripts, modernize them, and correct the documentation. Heck, I'll even fix the API documents too, since those are also junk.

[Bill Talley]

Hey Anthony,  now that you work for Cisco

<ducks>

[Anthony Holloway]

It is unfortunate that all of my past posts now look like a Cisco Employee wrote them.

[Anthony Holloway]

Basically, you just don't want to use the Select Resource step, and then never ever use the Connect step. The Agent selected will be stuck in the reserve state. It's that simple. Of course you can use a Goto step in there, just as long as, at some point, you then also use the Connect step to actually ring the Agent's phone.

How you have it now, with the Goto in the failed branch, going to the Queuing area, is just fine.

[James Hawkins]

Thanks Anthony,

I did some more troubleshooting and traced the issue that caused me to post this question to the fact that transferred calls to the application trigger number were be routed through a Translation Pattern rather than hitting the trigger directly - rookie mistake!

It would be really useful if Cisco took you up on your offer to optimise some of the sample scripts and API documentation.

I struggle with the latter - there are lots of cool things that could be done with the API but my enthusiasm wanes when things do not work as documented.

Do you ever attend the CCX Partner Summits that Cisco run? - they would be a good opportunity to pitch your offer to the CCX product management team.

[Anthony Holloway]

Tell me more about this summit. I've never been to one.

[James Hawkins]

Anthony have sent you a PM