Jump to: navigation, search

Rules Overview

A business rule is a piece of logic that defines, on a small scale, what a business does. For the Genesys Rules System, a rule is an external piece of logic that can be customized by business analysts, and invoked by applications. This allows you to tune specific business behaviors as needed.

Types of Rule

GRAT allows you to configure two types of rules: linear and decision tables.

Linear rules

Linear rules follow the following basic format:

WHEN {condition} THEN {action}

When the condition is true, the action will occur. This form of rule is best for simple actions, such as assigning a value to return back to the application. Note, however, that linear rules can have multiple conditions and actions, or only actions with no conditions. The conditions and actions that are available depend upon the rule templates that are included in the rule package.


If a customer’s age is within the range of 30-40 years, the customer’s interaction will be routed to Agent Group 1.

In the Genesys Rules Authoring Tool, create a new linear rule. Enter the name, phase, and so on, as desired, and then add a condition and an action. The phases from which the rules author can select are dictated by the rule template that the rules author is using.

There is an enumeration called Phases within the _GRS_Environment fact, that will be created whenever a new rules template project is created in the Rules Development tab. If the Phases enumeration is not present, the rules author will simply see * in the Phase dropdown. In this case, Phase will not be considered when evaluating the rule package.

The _GRS_Environment Fact must be provided for all rule evaluations. An empty _GRS_Environment fact must be provided for rules at the package level that do not use a Phase (that is, the Phase was defined to be * ).

The Add Condition and Add Action drop-down lists are populated with all of the conditions and actions that were created in the rule templates that are included in the rule package. The drop-down lists contain the language expressions that the rule developers used during creation of the components, and not the rule language mapping. This makes it possible to create rules without knowing the rule language mapping or being familiar with Drools.

The parameters that are contained in each condition and action are represented by the names that are entered for them. The business rule author must replace this name either by entering a value (such as for an age range) or by selecting an option from the drop-down list (such as for an Agent Group).

So, to create this rule, the rules author would select Age Range as the condition and enter 30 as the {ageLow} parameter and 40 as the {ageHigh} parameter. The action would be Target Agent Group, and Agent Group 1 would be selected from the {agentGroup} drop-down list.

More information

The following topics explain how to work with linear rules in GRAT:

Decision tables

Decision tables allow you to join a number of Linear Rules with the same set of conditions (when) and actions (then) to be used for a complex (structured) business case. Use decision tables to avoid dozens of linear rules with identical structure in the system.

  1. Choices in decision tables need to be mutually exclusive to avoid ambiguity. This ensures that there is only one outcome per evaluation. If the choices are not mutually exclusive, multiple rows can be executed, in no guaranteed order. The last row executed will determine the final result.
  2. The maximum number of columns supported in Decision Tables is 50.
  3. When you are editing rules, be careful not to clear your cookie data, as this might cause the rule to be lost. Consult the documentation for the browser that you are using for more information about how to prevent a user from clearing cookie data.

More information

The following  topics explain how to work with Decision Tables in GRAT:

Order of Execution

You can configure rules for various business contexts (nodes representing the various elements in your business structure hierarchy), or, for global rules, at the rule package level. In the navigation panel, each business context within the configured business structure is represented at a different node level. The order of execution of rules within a rule package depends on the node level: rules execute first at package/global level, then at each level of the hierarchy in turn.

So if you have defined this hierarchy:

  • Package
    • Sales Department
      • Finance

and during execution, you specify “Sales Department” / “Finance”, then the order of execution is:

  1. Rules at Package level (according to priority).
  2. Rules at Sales Department (according to priority).
  3. Rules in Finance (according to priority).

Within a given node, you can modify the order of execution by using the up Grs auth-tool up.gif or down Grs auth-tool down.gif arrows on each rule.

Only rules on a particular node path are executed in any given rules run. The path of execution is determined by input to the Rules Engine on the execution request.

The business structure is defined in Configuration Manager or Genesys Administrator.
System administrators can configure rule execution to be "bottom-up" or "top-down". The Rule Evaluation Order indicator at the bottom of the screen shows you which of these is selected, and a ToolTip is available when you hover your cursor over this indicator. Any changes made to this configuration will apply dynamically, but only take effect after a restart or a browser refresh.

Audit Trail

The Audit Trail tab allows you to view the history of the individual rules, such as when they were updated or deployed, and by whom. When accessed within a business context (a node on the Explorer Tree), the Audit Trail tab lists the rules that exist for that business context.

This page was last edited on August 30, 2019, at 20:05.
Comments or questions about this documentation? Contact us for support!