First, we will need to understand how the continuous script schedule type works. One very important aspect is how the script is handled by the system and how the system runs the script you have selected. The way the system runs the script is different than the way you may be thinking. During my first few uses of a continuous script schedule, I was not aware that the system will run the script every two minutes.
There are a few things we will need to consider when building a script that runs continuously.
- How long does the script take to complete?
- If the script takes longer than two minutes, is there a safety check in place to make sure your script is not running more than one instance at a time?
- Are there wait actions in place to limit how fast the script will run?
- When do you want the script schedule to begin?
If your script takes less than two minutes to complete you may not need to configure and checks; however, it is recommended to put some in place just to be on the safe side. If you are grabbing data from another system or looking up a lot of data, you may see your script take slightly longer and longer to complete as more and more data is being pulled. If your scripts take longer than two minutes to complete, you MUST add some checks to your script to make sure that there is only one instance running at a time. Failure to limit running scripts of this nature to one at a time may result in a call from Network Operations Control (NOC). This can be added simply by using a couple of get and put val actions and using an IF statement to end a script if it is already running. To do this just configure a get-val at the start of the script to look for a value, I like to use RUN. Then after the get-val, simply check on the return. If you are set to RUN allow the script to continue, if not just end. Right after the IF statement, set the value of RUN from TRUE to FALSE. This will stop the script form running again until we change the value to TRUE. At the end of your script, make sure the value is set back to TRUE and then end the script.
There is one other item to consider before setting up the schedule. I recommend adding in a few wait actions set to between .5 and 1 second after every 15 actions to give the platform some time to catch up and to make sure we are not creating latency on the server. Multiple actions pulling large amounts of data can cause issues and should be avoided when running in a loop.
The last thing to consider is, when to start the schedule. My recommendation is to have your scripts configured and ready to go, making sure the above items have been considered, and configuring the schedule to start on the next day. This will give you time for a few debugging runs of the script and make sure nothing needs to be changed before it is triggered every 2 minutes. This is a great time to verify the safety limits and wait times you put in place and make sure they are all working as expected.
At Frontline Call Center, we strongly believe in the benefits of advanced technology and have made extensive investments to ensure our capabilities remain cutting edge while giving our clients access to the highest quality technology solutions. Our philosophy is if you can dream it, we can build it and our tech’s stay up on the latest in technology employed in the cloud based call center arena to make this happen.
Frontline Call Center partners with industry leading contact center software provider, inContact. inContact is the time proven technology that helps deliver exceptional customer experiences while decreasing costs and increasing revenues. inContact gives us a strategic competitive advantage. Thousands of calls, chats, and emails run through our call center on a daily basis. Managing these contacts is an important task and crucial to maintaining our high levels of quality for our Clients.
Below are some screen shots of the actions I use to safely limit the number of concurrent running scripts.