Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

crs 4.x select resource behavior with multiple CSQs

I need to queue a caller to a second queue after sitting in the queue loop of an initial queue. I would like to do this by changing my csq variable, and goto'ing back to the same select resource step (so that the queue loop logic can be executed again if needed).

however, in the CRS4 scripting guide - there is this paragraph -

"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.)"

how can you NOT put a goto in a queue branch of a select resource step? don't you need a GOTO in order to loop?

in CRS3.x, we routinely used GOTOs in order to handle a failed condition of the Connect branch.

what is going on in CRS4 that this is differant behavior?




Re: crs 4.x select resource behavior with multiple CSQs

What its referring to is using a GoTo to remove a contact from the "queued" branch of a select resource step.

The best way to queue to another skill group is to do one of two things.

1. You can just simply add another "select resource step" for your new CSQ within the queued branch or your initial select resource. This way your caller will be queued to both CSQ's.

2. If you want to remove it from your initial queue, first use the "Dequeue" (all) step then use a GoTo step and send the call to a Label that has your new Select Resource step beneath it. Doing this will allow you to properly report on these types of calls because you will see a "dequeued call" in the CSQ reports.

andy dignan - berbee

please rate posts.

New Member

Re: crs 4.x select resource behavior with multiple CSQs

Thanks for the information.

We also discovered that if you are using a variable to queue a call into the CSQ, when you call the 2nd Select Resource, you need to use a new variable (you can't just change the value of the original variable). Otherwise, if an agent with the first skill goes ready to take they call, they go into a Reserved state, but the call never completes (the scripts stops at the first skill's select resource, but since the value of the CSQ variable now is differnat, it appears to get confused).

using two differant variables for each Select Resource appears to solve this problem.