Overview

In release 6.4, Cyara introduced Data Validation and Data Classification features, which share a common name CVA Data Rules.This feature co-exists with the legacy functionality ValidateUserData activity in CVA, however it is an independent module with different configuration and logic.

This article describes the basics of CVA Data Rules configuration and usage.

Agent Behaviors

Similar to the Test Cases for Voice (Web, SMS, Email) interactions, Cyara has a test case for CTI type of interactions called Behavior. Behavior Test Cases are associated with an Agent that is emulated by Cyara.

Each Agent Behavior consists of Agent activities similar to the Test Case Steps for Voice and other interaction types. Following are the definitions for these terms:

Agent Activity:  The individual actions within an Agent Behavior that a Virtual Agent can perform when processing an interaction.  Available activities vary by media type.  Examples of activities include answering a call, placing a call on hold, releasing a call, validating attached data, receiving a chat message and sending a chat message. The complete list of activities can be found in the User Guide.

Agent Behavior:  A sequence of agent activities to be executed in the listed order.  An example for a call would include answering the call, putting the call on hold, retrieving the call and releasing the call.   Each Virtual Agent can be assigned a single behavior per Campaign.  Each Virtual Agent can be assigned any available Behavior.  For example, agents connected to Gold queues may have a different agent behavior from those connected to a Silver queue. 

Shown below is a basic Agent Behavior associated with a call.  Note the sequence of activities and the order that these activities will be executed. 

Basic Behaviors are very useful when the actions of the Agent can be consistently performed over and over again. This assumes the Virtual Agent is not required to change the sequence of activities throughout the Campaign.

Limitations:  There are limitations to the application of a single Behavior for all Virtual Agents within a Campaign:

• Virtual Agents receive different types of calls as they are connected to multiple queues, with each call requiring a different set of activities or behavior – “One size does not fit all” if each queue requires a different behavior.
• Creating behaviors for all possible types of arriving interactions, (calls & chats) would require creating a large number of behaviors. Every type of call or chat that requires a different sequence of activities requires a unique behavior. Validation of attached data, for example, can often lead to large numbers of behaviors as the data to be validated varies by call.

Classification Rules

In the Agent Behavior shown in the preceding example, Cyara validates user data attached to the Agent Interaction activity #3. In the example, the wildcard lets Cyara accept any value. But how do we validate individual values? What if the value of CustomerSegment changed with each call type?  Call 1 is Gold, call 2 is Silver and so on.  A single behavior validating the value of the attached data, CustomerSegment, to be Gold would fail on the second call.

How do we get a single behavior that can handle multiple types of calls each with different activity sequences?

Use Case:  Virtual Agent is connected to multiple queues in order to take credit card calls, checking account calls, savings account and refused transaction calls.  Four different types of calls with four different behaviors to be assigned to the same Virtual Agent; different CTI Data, different CTI actions and different timings.

Solution:  Use Classification Rules to create a single behavior that can vary the agent activities within the behavior according to the type of call received.  Classification Rules use the classification of an interaction to determine which activities within a behavior will be performed and which activities will be skipped.  

A Classification Rule is a designation that reflects an analysis of the data associated with the interaction. The associated data can be CTI data attached by the IVR or routing engine, or Virtual Agent-level information known to Cyara. The classification can reflect the evaluation of a single item of CTI data or multiple items of CTI data.

General configuration workflow:

• Each Behavior can be assigned with a Classification Rule
• Each Classification Rule can have an unlimited number of classifications
• Each Agent interaction can be associated with a single classification 
• An unlimited number of Classification Rules can be created

Configuring Classification Rules

A Classification Rule uses a table format to configure possible variations (classifications) in the Interaction Data.

The Classification Rules table is made up of rows and columns

• Rows represent the Classification Rule
• Columns represent the criteria

In the screenshot below, we will assign the interaction the classification of Credit Card if the attached data key called x-act_Type has a value of Credit_Card (case sensitive):

If the attached data key is not present or has a different value than Credit_Card, the interaction will not be given a classification. 

Clicking “New Property” allows you to populate the column to the right of the “Description” column.  The Display Name is what is shown as the column header.  The content of the column reflects the value associated with the Key Name for which a match will bring about the assignment of the classification.

Each column in a row is a logical “and” when evaluating all the criteria thus an interaction must have the Customer Value attached data equal to Diamond” and Transaction Type attached data equal to Credit_Card for the interaction to be classified as Credit Card.

If the first row does not result in a classification of the interaction, the second row is tried.  If that fails, the third row is tried and so on until the table is exhausted. 

In our example, any property cell, “Customer Value” or “Transaction Type” that does not contain any value in a row is evaluated as “any value is acceptable”.

If no rows produce a classification, the interaction is considered “not classified”.

Applying Classification Rules

In the example behavior shown, each activity classified as “All” is executed no matter what.

The 3rd activity is executed if the interaction to which this behavior has been applied has been classified as Credit Card according to the “Interaction Type Classify Rule” shown in the last slide.

If an activity is designated as “No Match” in the Classification column, the step will be executed if none of the classification rows were applicable. 

Classification Rules along with associated Activities can produce a single Behavior that supports a number of interaction types; no more one behavior for each unique interaction type.

As there is no limit to the number of activities in a behavior and there is no limit to the number of rows in a Classification Rules table, planning the call flows for all call types including Classification Rules and Activity Steps is highly advisable.

Data Validation Rules

How do we validate large volume of Interaction Data without resorting to crazy large Classification Rules Tables to accommodate every possible combination of attached data?

Use Case:  Interactions are delivered to the Virtual Agent carrying various CTI data elements.  There are situations in which a Classification Rule will utilize a small number of the total CTI data elements to properly classify a call while there are a number of remaining CTI data elements that also need to be validated. 

Solution:  A Validation Rule allows for an unlimited number of CTI data elements to be validated in conjunction with a Classification Rule.  A Validation Rule allows for the use of a table of rows and columns to validate the presence and value of any or all of the CTI data associated with the interaction. 

Purpose:  To validate the CTI data associated with an interaction that has been classified per a Classification Rule. 

Rules:  A validation rule looks to match the actual data associated with an attached "data key” with the expected value as listed in the Validation Rules table. 

The associated data can be CTI data attached by the IVR or routing engine. The associated data can be Virtual Agent-level information known to Cyara.

The validation can reflect the evaluation of a single item of CTI data or multiple items of CTI data.
Each Classification Rule can have multiple Validation Rules.

 A Validation Rule can be connected to single Classification Rule

How:  Create a Validation Rule by clicking “Data Rules” from the “Agents” menu and selecting “Validation Rules”.

Creating a Validation Rule

The Validation Rules table is made up of rows and columns

• Rows represent the validation rule
• Columns represent the criteria

In this example, we are going to validate that the attached data element with the Key Name of Customer_Segment has the value of “Gold” (case matters).

Cyara will look for a specified key in the attached date of the interaction received from the CTI server and apply the validation rule.

If the attached data key is not present or has a different value than “Gold”, the validation is considered to have failed. 

Clicking “New Property” allows you to populate the column to the right of the “Description” column.  The Display Name is what is shown as the column header.  The content of the column reflects the value associated with the “Key Name” for which a match will bring about a successful validation.

The Validation Rules table can have as many rows and columns as needed. The rules are evaluated one row at a time from top to bottom. 

Each column in a row is a logical AND when evaluating all the criteria thus the first row must have the Classification of the correct type, CustomerSegment attached data equal to “Gold” and Entry_zero_out equal to “Yes” for the validation process to be classified as successful. 

If the first row does not result in a successful validation of the data, the second row is tried.  If that fails, the third row is tried and so on until all the rows are exhausted. 

Any property cell, Customer Segment or “Early Zero_Out in our example that has a value of “empty” in a row is evaluated as “any value is acceptable”.

If no rows produce a successful validation, the validation process is judged to have failed.

Applying Validation Rules

In this example behavior shown below, each activity with  as “All” is executed no matter what.

The third and fourth activities are executed if the interaction to which this behavior has been applied is classified as Credit Card according to the Interaction Type Classify Rule.

Activity #4 will execute the Data Validation Rule entitled Customer Segment Validation, if appropriate.  The Continue on failure option is selected to allow the behavior to continue processing if activity #4 returns a failure status. 

As there is no limit to the number of activities in a behavior and there is no limit to the number of rows in a Validation Rules table, planning the call flows for all call types including Classification Rules, Validation Rules and Activity Steps is highly advisable.

Cyara Validation and Classification Rules FlowChart

The use of Data Rules allows for Virtual Agent Behaviors to address greater usage models with less work than prior versions of Cyara.

Few guidelines to keep mind while using Validation and Classification Rules:

• There are three primary use cases for Virtual Agent Behavior (no classification, only classification and classification with validation).  Use the most appropriate for your circumstances.
• Plan the Classification and Validation Rules before you attempt to deploy.  It will save you time in the long run.
• Syntax for all attached data items is critical.  Pay special attention to capitalization and non-alpha characters in the names.
• Develop a naming strategy for all Data Rules in the same way as naming strategies for Behaviors, Test Cases and Blocks is recommended.