Object Specific Variables in Cisco ICM

In all my time working on solutions that include Cisco ICM I have encountered very few people who are aware that you can create global user variables that are specific to a type of configuration object. I am guessing that many of you are thinking “what the heck are you talking about?”, so let me explain.

First, let’s start with what a Global User Variable is. Global User Variables are simply variable data storage spaces that aren’t specific to a call. You configure Global User Variables in the User Variable List Tool within ICM configuration manager.

Screenshot 2014-11-09 12

If you have created a Global User Variable before you have probably noticed that there are a whole list of object types that you can choose from, most of which we all just cruise by on our way to the last choice: “User Variable”.  After all, why the heck would we create something other than a user variable with the user variable list tool, right?  Turns out there is good reason Cisco put all those choices there, which we will get to in a minute, but for now let’s focus on what happens when you create variables with an object type of “User Variable”.

Let’s use the following functional scenario to illustrate how global user variables are used in a contact center:

  • The center has 2 lines of business that are serviced by the ICM or UCCE platform; Sales and Support
  • Each line of business utilizes a 3rd party to handle overflow volume and off-hours calls.
  • The business wants to control when the overflow happens and the number that the overflow calls will be sent to without editing the routing scripts.

To accomplish this we need a variable for each line of business that tells the routing scripts if they should send new inbound calls to the 3rd party, this will simply contain a single character “T” or “F” (could be 0/1 or Y/N if you prefer) indicating true of false.  We also need a variable for each line of business that tells the routing script the phone number of the 3rd party that the call should be sent to when the overflow indicator is true.  This means we need 4 global variables in all, and if you created them as type “User Variable” you would end up with 4 records in the User Variable List:

Variable Name Object Type Data Type Description
user_Sales_Overflow_Active User Variable Character ‘T’ or ‘F’ indicating if overflow is active for Sales
user_Sales_Overflow_Number User Variable Character Phone number where Sales overflow calls should be sent
user_Support_Overflow_Active User Variable Character ‘T’ or ‘F’ indicating if overflow is active for Support
user_Support_Overflow_Number User Variable Character Phone number where Support overflow calls should be sent

Here is what our User Variable List looks like with these 4 variables created:

Screenshot 2014-11-11 21.05.34

When we use these newly created variables in a script, using a Set Variable object for example, we access them by choosing global for the Object Type and leaving the Object unselected.

Screenshot 2014-11-11 22.08.06

Now that we’ve taken a look at how most people use Global User Variables let’s examine how Object Specific Variables, or OSVs, differ from this more traditional method of User Variable usage.

One noteworthy point here is that “Object Specific Variables” is a name I came up with for this type of configuration, not a standard set by Cisco or the ICM documentation, so if you tell someone at Cisco your using OSVs they are going to have no idea what you are talking about unless they happened to read this.

The key difference with OSVs is that we choose an “Object Type” other than “User Variable” when creating the variable itself.  There are a number of types that can be chosen from the list but the concept is the same for each.  I will use Call Types as the Object Type for the purpose of this example but you should choose the type that makes the most sense for your function scenario.

We’ll use the same functional scenario we did previously.  Since we are using Call Types for our objects here, lets begin with creating one for each of our lines of business.

Call Type Name Description
LoB_Sales Utility Call Type for Sales
LoB_Support Utility Call Type for Support

Screenshot 2014-11-12 11.01.33

Next we create our variables in the User Variable List and select “Call Type” for the “Object Type”.  You will notice that we only create 2 variables this time.  This is because ICM will make these 2 variables accessible for every Call Type object.

Variable Name Object Type Data Type Description
user_Overflow_Active Call Type Character ‘T’ or ‘F’ indicating if overflow is active
user_Overflow_Number Call Type Character Phone number where overflow calls should be sent

Screenshot 2014-11-12 11.04.10

With the variables created we can head back to the script editor and see the variables are available on each of the call types we created before.

Screenshot 2014-11-12 11.06.40

Now that you are an expert on how to create OSVs let’s turn our attention to why we would use OSVs instead of the normal User Variables we are probably used to.

The first, and probably most obvious, reason is because it keeps forces the use of standard data types and names when new lines of business are created with common functionality.  This probably seems nominal advantage when you look at the simple example we used here but when you have 50+ lines of business you will appreciate not having to add multiple variables for each or trying to figure out what someone else named the variable you expect to be called “user_overflow_active”.

The other advantage of OSVs, which probably does not jump out at you, is you can pass the object into a custom function and use the variables in a repeatable way. Let’s consider an example using the following OSVs:

Variable Name Object Type Data Type Description
user_Holiday Call Type Character ‘T’ or ‘F’ indicating if the current date is a Holiday
user_Emergency Call Type Character ‘T’ or ‘F’ indicating if the center is shut down for an unexpected emergency situation
user_OpenHours Call Type Character ‘T’ or ‘F’ indicating if the current time is within normal business hours

In this scenario we want to combine checks for emergency closure, time of day, and the occurrence of a holiday to determine if the line of business is open.  We can use a simple custom function, which we will call user_IsLoBOpen(), to evaluate the variable’s values in standard way for each line of business.  Our function will accept a single parameter of a Call Type, which we would pass to it like this: user_IsLoBOpen(CallType.LoB_Sales).

The function itself would look something like this:

if(%1%.user_OpenHours=="T"&&%1%.user_Emergency!="T"&&%1%.user_Holiday!="T", "T", "F")

I hope this was helpful. I would love to hear your thoughts so drop me a comment. Happy scripting!

2 Comments
  1. Brad Clarke January 26, 2016 Reply
    • Michael Aossey January 29, 2016 Reply

Leave a Reply

Your email address will not be published. Required fields are marked *