A formula consists of one or more expressions that the scripting environment evaluates to produce a value that it can use for subsequent script processing. You define expressions—made up of variables, constants, operators, and functions—as part of custom selection rules or distribution criteria in scripts. (See the sections on variable usage, selection of targets by rules, and distribution of contacts to targets.)

This is an example of a simple formula:

CallerEnteredDigits == 1

In this example:

• The left value, CallerEnteredDigits, is a variable. More specifically, it is a call control variable.

• The operator is the "Equal To" equality operator.

• The right value is the number 1.

If the value of CallerEnteredDigits is 1, the formula returns true; otherwise, the formula returns false.

A variable is a named object that holds a value. You use variables in formulas to select targets and help in call tracking.

Following is the syntax for using a variable in a formula:

object-type.object-name.variable-name

Where:

• The object-type is an object category, such as Service.

• The object-name is the name of an object contained in Unified ICM database, such as the name of a service (for example, BosSales).

• The variable-name is the name of an object that can hold a value, such as a call control variable (for example, (CallerEnteredDigits).

• Each component in the variable is separated by a period (.).

Note	Passing of internationalized characters through Media Routing interface is not supported. The application that interacts with ICM through the Media Routing interface must send any call related data in English only.

A single-target variable examines data for one specified routing target. For example, the variable:

Service.BosSales.ExpectedDelay: Examines the expected delay for the BosSales service.

A multiple-target variable examines data across multiple routing targets. For example, the function:

Max(SkillGroup.*.LongestAvailable): Finds the skill group, from all skill groups defined in the target set for the script node that calls the function, with the longest available agent.

You use an asterisk (*) as the object-name value to indicate that the variable is to examine data across multiple targets.

Call control variables provide information about the current contact that is being routed by the script. Call control variables include information about where the route request came from, contact classification data, and data to be passed to the peripheral that receives the contact.

Note

For a Post-Routing® request from an Aspect ACD, PeripheralVariable1 through PeripheralVariable5 map to the Aspect variables A through E. The Aspect routing client passes these variables to the Unified ICM as part of the request and the Unified ICM returns them with the response. Other routing clients might use some of these variables for other purposes. The values of these variables are also stored in the Route_Call_Detail table of the database.

Note

The Call Variables can be used in a "SET" node in an Admin Script as temporary placeholders for complex calculation. However, because any call context is only existent as long as the call itself, the Variables cease to exist after the Route Request (a.k.a Call) is complete (be it by virtue of a successful Routing Script Execute Completion or an Administrative Script Execute Completion). They cannot be used to store values, so as to be re-used in Routing Scripts, as the Routing Scripts themselves will have a new set of CallVariables created for the Route Request.

Note

When comparing two Call Variables of Numeric string, you must use the Built-In Function "value()" in the IF Node to perform Numeric comparison, otherwise there is a String comparison. Example: value(Call.PeripheralVariable1)>=value(Call.PeripheralVariable2) where Call.PeripheralVariable1 and Call.PeripheralVariable2 are given as Numeric string.

Expanded call context (ECC) variables store values associated with the contact.

ECC values are written to Termination Call Detail records only if, and when, an ECC value is explicitly set. You can set the variables in several ways, such as using a script, a VRU, a NIC, CTI, and so on. This applies to null values as well as non-null values.

If an ECC variable is defined, but never assigned a value, it does not have a row in the Termination Call Variable table when a Termination Call Detail record is written.

The Latin 1 Character set for expanded call context variables and peripheral call variables is supported when used with Unified CVP, Cisco Finesse, and Cisco SocialMiner, among others.

The use of multi-byte character sets in limited usage for ECC and peripheral call variables is also supported, when:

• Setting them in the Script Editor using double quotes.

• Stored in Termination Call Variables with an appropriate SQL collation.

• Setting and receiving them through agent desktops.

ECC values are generally passed from leg to leg on the call. After a value is assigned, the value is recorded in the Termination Call Variable for every Termination Call Detail Segment. However, this depends on how each new call segment is created. If it does not involve translation routes or the Unified CCE, and is outside the original peripheral, then the solution cannot propagate ECC variables, like all call variables.

The solution comes with some predefined ECC variables. You can create others througn the Configuration Manager.

When the Unified CCE/Unified ICM writes call data records to its historical database, it can store the values of all call variables. Storing excessive call variable data can degrade historical database performance. When you define a call variable (in the Configuration Manager), you can tag it as either persistent or non-persistent. Only persistent call variables are written to the historical database. You can use non-persistent variables in routing scripts, but they are not written to the database.

You must create several ECC variables if you intend to use Enterprise Chat and Email and/or Voice Media Routing Domains to route Delayed Callback requests. The ECC variables are:

• user.ece.activity.id - used to send the CIM activity ID to Unified ICM.

• user.ece.customer.name - used to pass the customer name from the entry point to Unified ICM.

Warning

Do not overwrite reserved ECC variables in a script. Overwriting these variables may cause the application to route tasks to agents in an incorrect manner.

For more information about configuring ECC variables, see the Configuration Guide for Cisco Unified ICM/Contact Center Enterprise.

User variables are variables you create to serve as temporary storage for values you can test with an If node. For example, you could create a user variable called usertemp to serve as a temporary storage area for a string value used by an If node.

You create user variables through the Configuration Manager. For more information, see Configuration Guide for Cisco Unified ICM/Contact Center Enterprise.

Each user variable must:

• Have a name that begins with user.

• Be associated with an object type, for example, service. (This enables the Unified ICM to maintain an instance of that variable for each object of that type in the system.)

• Store a value up to 40 characters long.

After you have define a variable, you can use the Formula Editor to access the variable and reference it in expressions, just as you would with a built-in variable.

You can set the value of a variable with the Set Variable node:

• Object type - Choose the type of object the variable is associated with.

• Object - Choose the specific object the variable is associated with.

  Note	If you choose Call as the Object Type, this field does not apply.

• Variable - The specific variable you want to set.

  Note	The variables that are available are determined by the value you choose in the Object Type field.

  Note	Define all integer fields in tables accessed by a Set Variables node as NOT NULL.

• Array index - Enter an integer or an expression that evaluates to an integer. For example, if the Array Index expression evaluates to 2, then the Set Variable node sets the second element of the variable array.

  Note	This field is only available if you select an array variable in the Variable field.

• Value - Enter the value to assign to the variable. The value can be:

  • A constant

  • A reference to another variable

  • An expression

When the Unified ICM system includes only the voice channel, the value of the SkillGroup.Avail variable is the number of agents in the available state, meaning that the agents are able to accept new calls.

However, when the web or e-mail channel is used with non-voice Media Routing Domains and agents log in to multiple domains, the value of the SkillGroup.Avail variable is calculated differently. There is also a SkillGroup.ICMAvail variable.

The following table describes the difference between the SkillGroup.Avail and the SkillGroup.ICMAvail variables:

The value of the SkillGroup.ICMAvailable variable is the actual number of agents logged in to the skill group who can take new calls or tasks. Such agents must meet all the following criteria:

1. They are routable in the domain.

2. The agent's state in the domain is something other than "Not-Ready".

3. The agent is below the maximum task limit.

   Note	For most domains (that is, if the agent is not a Enterprise Chat and Email Multi-session agent), the maximum task limit is 1, and an agent is below the maximum only when the agent is not working on any call or task.

4. The agent is not working on another task in a non-interruptible domain.

SkillGroup.Avail is the number of agents in the skill group who are not doing anything in the domain. An agent who is logged in to two domains can be counted as Avail in one domain even though that agent is handling a task in another non-interruptible domain. An agent in a domain that handles multiple tasks (such as chat) is not counted as Avail if that agent is handling a task, even though the agent has additional capacity for more tasks.

The following table shows some possible values for these variables. Assume three agents are logged in to a voice skill group, and the same three agents are also logged in to another non-interruptible domain, such as a chat domain. This table shows the voice skill group states and the number of agents available in that state.

If a routing script needs to check the number of available agents, using SkillGroup.Avail produces effective results as it uses an extrapolation mechanism in determining the available agent.

Following is another example showing agents handling non-interruptible chat tasks. Assume three agents are logged in to a chat skill group, each allowed to handle two chats. This table shows states for the chat skill group.

By default, Script Editor shows the ICMAvailable value instead of Avail value when displaying skill group real-time data.

Closed variables are available for use for skill groups, peripherals, and Media Routing Domains. Closed variables allow administration scripts to turn dequeuing to these objects on and off. The Closed variables default to 0, meaning that the object is open. A script (usually an administration script) can change the state of the Closed variables.

If a Closed flag is set to a non-zero integer, then calls are not dequeued to affected agents, regardless of their state.

When closed variables are set to zero, the queued calls do not go to the available agents immediately, and continue to be in the queue. When the agent state changes from "Not Ready" to "Ready" state, the new calls are sent to the available agents (agents in the "Ready" state) only, and not the queued calls.

The following table shows the order in which operators are evaluated.

Note

The operators with priority 1 are evaluated first, then those with priority 2, and so on. The order of evaluation within each priority level can also be important. Prefix operators are evaluated from right-to-left in an expression. Assignment operators are also evaluated from right-to-left. In all other cases where operators have equal priority, they are evaluated left-to-right.

The Prefix Operators in the following table take a single operand:

The Arithmetic Operators in the following table take two operands:

The Equality Operators in the following table take two operands:

The Relational Operators in the following table take two operands:

The Logical Operators in the following table take two operands. Logical operators examine the values of different logical expressions:

Note	The equality (==) and relational (>) operators are evaluated before the logical operators (&& and ||).

The Bitwise Operators in the following table take two operands.

The following table lists miscellaneous operators:

The following table lists the built-in date and time functions:

The following table lists the built-in mathematical functions:

The following table lists the built-in miscellaneous functions:

Custom functions are those functions you create for use within scripts, as opposed to built-in functions.