Thank you Walter for your reply.

Can I change the call priority after Ring No Answer? so that when thecall is thrown back in queue, it is put in the front of the queue and not back in the last queued call.

It should be a way to do it in the script. I think that could add a counter and checked the value of the counter when the call is returned to the queue.

Actaully the idea of RONA does not exist in UCCX.  However, Ring No Answer (RNA) does exist.  And the RNA timer in UCCX needs to be shorter than the RNA timer in CUCM.  By default they are 10 and 12 respectively.

If an RNA happens, the caller is never taken out of queue, and therefore you do not need to increase priority and send back in.  The caller is automatically sent to the next available Agent.

Also, even if you wanted to, you couldn't assign a new priority to a caller after an RNA, *and* there are more Agents available to take the call.  You could only do it to the last available Agent in the pool.

As a test try this with 2 ready Agents, letting the call RNA on the first Agent, and see if the msg gets set:

Select Resource
  Selected
    Connect
      Connected
        End
      Failed
        Set msg = "This will not execute if there are available Agents in the pool"
    Queued
      ...

My money says it will not set.

Now, do it again, but let it RNA on both Agents, and then it will set, but only for the second RNA.

Summary: You can handle RNA, but only for the last available resource in the pool.

We are fine to handle RNA only for the last available resourece in the pool as this is not the default call coverage. What we really need is to set the call with higher priority before the call is put back in the queue and no agent is available to take the call. So i think the following should work.

Select Resource
  Selected
    Connect
      Connected
        End
      Failed
        Set Priority (Increas:1)  

Queued
      ...
Thanks.

I'm rather new here but, I do something like this for one of my teams.  I queue for a resource, if that rings out, the script heads on down to a queue for a team.  I loop within the queue and increase the priority with each loop.  If anyone can see why this is not a good idea, please let me know, I'm still learning, thanks.

There are a small number of things wrong with what you are doing in that script.  I would advise you to not highjack this thread, but instead, create a new thread for the purpose of reviewing your script.  I'll be sure to watch for your new posting, and reply with my recommendations.

EDIT: For fear that you may never post your own thread, and I am about to lose my notes on this, I am posting my recommendations here.  I figure, it's better to help you, and enforce bad habits, versus not helping you, and sticking to my guns.  =)

Here are my notes:

1. The delay 1 second after the answer.  Typically, you delay at the beginning of a script to relieve a race condition with handing off call redirects from one script to another, but in order for that to be effective, the delay has to come before the Accept step.  It's also usually a 2 second delay.  However, this is not even required, it's reserved as a troubleshooting step if you are having problems with your scripts.  So, unless you intended for there to be 1 leading 1 second of silence immediately following the Accept step, this step should be removed.

2. I'm not sure how or why you are selecting an individual resource at this point, and there may be issues with that piece as well, but I do know that you cannot queue to resources, so your Deuque step on the failure to connect is not doing anything.

3. Your Continue annotation under the Connected branch is allowing the script to fall through to the QUEUED label and subsequently the Select Resource step.  Which at this point causes a an error, and makes the system work harder than it needs to.  You should be cleanly ending the script here instead.

4. Just like the issue #3 above, your Continue under the second Select Resource falls through to the Terminate step and causes an error, and thus makes the system work harder.  Clean ending.

5. Increasing the priority of the caller for every loop iteration does absolutely nothing for the caller.  It make give you a reporting metric your looking for, as some reports include the priority of the caller.  But I doubt you are doing that here for that reason, and probably mistook the intention of the set priority step.  The system will naturally organize the contacts in the queue (FIFO) and ensure fair routing without you doing anything.

6. You can delete the terminate step all together as it's never actaully executed (properly) in your scripting logic.

A new revised script for you may look like this:

Start
Accept
calledAgent = Get User
     Successful
          Select Resource
               Connected
                    End
               Failed
                    /* Continue */
     Unsuccessful
          /* Continue */
Select Resource
      Connected
           End
      Queued
           Label Queue Loop
           Play Prompt
           Goto Queue Loop

This new script has 11 steps (versus your original 16)

When routing to an Agent it executes 4 steps (versus 7 and an error)

When routing to an Agent fails, and then routing to a group member it executes 6 steps (versus 10 and an error)

I look for speed and effeciency in a script.

When Cisco tells you that the product can termiante 300 calls at the same time, do you think they account for the best scripting, or worst scripting possible?

Thanks for moving your post over to this new thread, and welcome to UCCX!

Also, would you care to ellaborate on why/how you are doing the select resource to a resource?

Message was edited by: Anthony Holloway - "Against my will"

Thanks Andy, however, your charge that I am intending to hijack the thread is incorrect and unappreciated.  My intention was to possibly help someone, not to have anyone audit my script.  My comment to let me know if this is a bad idea was simply to reiterate that I am new and just learning this stuff.  I can see that Cisco's arrogant culture permeates past the corporate bounds.  I'll leave the question answering to you obviously more knowledgable and experienced script writers from here on in.

I'm sorry you feel that way about the community.  I'm positive everyone is only here to help.  Hopefully you'll find that to be true as well.