Routing_Strategy
A set of decisions and instructions that are created in Interaction Routing Designer (IRD) and that tell Universal Routing Server (URS) how to direct incoming customer interactions under different conditions. Can be contained in an Interaction Workflow. Can use subroutines, routing rules, business rules, attributes, interaction data, statistics, schedules, lists, and macros. Can apply logic (for example, segmentation, conditional branching, and so on). Can deliver the interaction to an agent or another target type, such as an ACD queue, agent group, campaign group, destination label (DN), place, place group, queue, group, routing point, skill group, or variable.
Glossary
Contents
Routing Strategies for Sensitive Data
For channels other than Chat, you must use Composer or Interaction Routing Designer (see the Universal Routing documentation) to create strategies (or modify existing ones) that include an External Service object that calls one of the following methods:
- IxnByGroup—This method specifies an interaction in the UCS database and the group of rules to apply to it. Its parameters are listed below.
- DataByRegex—This method extracts the text to be screened from the interaction as it passes through the strategy and the regular expression to apply to the text. Use it when you do not want to (or cannot) retrieve the interaction from the UCS database. In addition to the External Service object, strategies using this method must include some strategy object that extracts content from the user data and puts it in a variable which it passes to the External Service object. The parameters of this method are listed below.
Sample Strategy
The following strategy illustrates the use of both methods on an email interaction:
- In the first External Service object, IxnByGroup looks at the interaction in the UCS database and scans its entire content: Subject, Header, Body. It also updates the content of the interaction as stored in UCS, replacing any sensitive data that it finds with strings of * (asterisks). However, IxnByGroup does not affect the interaction's User Data, which contains attributes, such as Subject and various headers, that might also contain sensitive data. For that we must use DataByRegex.
- Two Function objects retrieve the content of the Subject and Thread-Topic.
- A Multi-Assign object creates a variable CreditCardRegEx and assigns it a value consisting of a regular expression that finds credit card numbers.
- In the second External Service object, DataByRegex scans the content of the Subject field.
- The following Function object updates the interaction (in the Interaction Server database), substituting * for the found data.
- The third External Service object does the same for the Thread-Topic field.
- When the interaction is terminated, the User Data attributes are also updated in the UCS database.
IxnByGroup Parameters
Parameter | Type | Description | Mandatory? | Default Value |
---|---|---|---|---|
Group | String | ID of the rule group to be applied. Either Group or GroupName may be specified, but not both. If both are specified an Error is generated. If neither is specified, the predefined Email group is used. |
N | No default value |
GroupName | String | Name of the rule group to be applied. Either Group or GroupName may be specified, but not both. If both are specified an Error is generated. If neither is specified, the predefined Email group is used. |
N | |
IxnAccessSpec | List | Specifies which parts of interaction stored in UCS should be processed, and other parameters needed for Ixn. Ucs Access Provider. This string is passed to the Provider and is used by the Provider exclusively. The string has the following form: key:value=<part>:<operation>, where part can be Subject, Header, Text (body), StructuredText, Content (MIME content), or _EmailAll (all fields) |
N | key:value=_AllEmail:update |
IxnList | String | List of IDs of interactions stored in UCS, separated by the pipe character ( | ). If absent, the Interaction ID is taken from user data. | N | No default value |
ProcedureOpt | String | Sets the output type of the procedure:
|
N | final |
DataByRegex Parameters
Parameter | Type | Description | Mandatory? | Default Value |
---|---|---|---|---|
DataList | List | Specifies the data portions to process: a list of key-value pairs, where the key is the reference ID of this data portion and the value is a string specifying the data portion to process. | Y | No default value |
Procedure | List of K-V pairs | Describes find and replace procedure by direct explicit specifications of its steps.
|
Y | No default value |
ProcedureOpt | String | Sets the output type of the procedure:
|
N | final |
Key | Type | Description | Default Value | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
TheOrder (optional) | Integer | Specifies the order of this part of the procedure. If Procedure contains only one step then TheOrder can be omitted. Otherwise TheOrder must be specified for each step of the procedure, and each step must have a different value. | No default value | ||||||||||||||||||||
RegEx (mandatory) | String | Regular expression used to process the data | No default value | ||||||||||||||||||||
ReplacementPattern (optional) | String or K-V list | Replacement pattern applied in data processing.
|
See embedded table to left |
Response
The response to the above methods is Event3rdServerResponse, which has the following parameters:
Key | Type | Description | Default Value | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
OutDataList | List of lists | Key is the reference ID of the original data portion: the interaction ID or the reference ID of the data portion in the DataList parameter of the request. The value is as follows
|
No default value |
Key | Type | Value |
---|---|---|
"start" | String | Starting position. The first character in a string is numbered 0. |
"end" | String | Ending position. |