Jump to: navigation, search

Follow these steps to create a new decision table:

  1. Navigate to the rule package to which the new decision table will belong in the Explorer Tree (verify that you have selected the correct Tenant from the Tenant drop-down list). Navigate to the correct node of the business structure under the rule package, which will define the node at which your decision table will be created. If you create the decision table at the rule package level, it will be a global rule. Select the node in the Explorer Tree and click the Rules tab.
  2. Click New Decision Table.
  3. In the Rule Summary, the ID field is populated automatically. It cannot be edited.
  4. Enter a Name for the decision table (for example, Status).
  5. Enter a brief Description for the rule (for example, Adjust the priority, depending upon the customer's status).
  6. Select the Phase at which this rule will be applied (classification, prioritization, or archiving for iWD. Refer to the Genesys Rules System Deployment Guide for more information about phases).
  7. Select the Business Calendar to use with this rule (optional).
  8. Enter a Start Date and an End Date for the rule (optional). If the End Date is earlier than the current date, the rule is marked with a flag (Grs auth-tool flag.gif ) to indicate that the rule is out of date.
  9. Use the up and down arrows in the far right-hand column to control the ordering of the decision table rows. In some complex cases, rules can be designed so that multiple rows will evaluate as true. In this case, the order of the rows becomes important, so in release 8.5.0 you can re-order the rows when creating and editing a decision table.
    10. Important
    By default, up to release 8.5.0, rules were executed from the bottom up. In release 8.5.0, your 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.
  10. Add Conditions and Actions in the lower panel.
    11. Important
    In release 8.5.001, you can now use a wildcard symbol (*) in row data in a decision table (if the feature is configured by administrators). The wild card indicates that, for this row, the value for the parameter where it is used is unimportant and not to be evaluated. A wildcard selection now appears at the top of all lists, regardless of whether they are enumerations, business attributes, Configuration Server, database, and so on. In the case of numeric parameters, you must type in the wildcard value—GRAT now accepts that as a valid number field. For any condition that contains one or more wildcards, its evaluation will not be considered in the rule logic. There are some restrictions:
    • The wildcard values will work only for strings and numeric fields—fields of type date, time and Boolean are not supported.
    • Wildcard values are "all or nothing" for conditions with multiple parameters. For example:
    Customer age is between 40 and 60
    is ONE condition, and it will be excluded for that row if one or more of the fields contains a wildcard value.
    1. Select one or more Conditions from the list (for example, a condition for this scenario might be named Customer's age is ...).
    2. Select one or more Actions from the list (for example, an action for this scenario might be named Increase priority by xxx).  
    3. Insert values for the parameters into the table under the Condition and Action columns. Depending on how the parameters were configured by the rule template developer in GRDT, there may be constraints on the values that can be entered.
    4. Repeat Step c, adding more condition and action values.
    5. Re-order the rows as appropriate.
  11. Click Validate to validate the syntax of the linear rule.
  12. Click Save to save your changes.
Important
When you make any modifications to the body of a rule, you "lock" the rule, which prevents others from being able to make changes to the same rule at the same time. The unsaved icon Grs auth-tool unsaved.gif will appear on the rule summary to alert you that you need to save your changes. For any other user, the locked icon Grs auth-tool lock.gif appears on the rule summary and the Save and Cancel buttons are disabled. In addition, other users are unable to make changes to the rule because it is marked "read only".
Important
When editing rules, be careful not to clear your browsing history or cookie data, as this might cause the rule to be stuck in a locked state. Unsaved changes could be lost.
Important
The Pending Snapshot field indicates whether any snapshot of this rule has yet been created. See Deploying Rule Packages for information on snapshots.

Follow these steps to create a linear rule:

  1. Navigate to the rule package to which the new rule will belong in the Explorer Tree (verify that you have selected the correct Tenant from the Tenant drop-down list). Navigate to the correct node of the business structure under the rule package, which will define the node at which your linear rule will be created. If you create the linear rule at the rule package level, it will be a global rule. Select the node in the Explorer Tree and click the Rules tab.
  2. Click New Linear Rule.
  3. In the Rule Summary, the ID field is populated automatically. It cannot be edited.
  4. Enter a Name for the rule (for example, Gold).
  5. Enter a brief Description for the rule (for example, If the customer is a Gold member, then increase the priority).
  6. Select the Phase at which this rule will be applied (classification, prioritization, or archiving for iWD. Refer to the Genesys Rules System Deployment Guide for more information about phases).
  7. Select the Business Calendar to use with this rule (optional).
  8. The Pending Snapshot field is displayed with a tick symbol indicating that the contents of this rule have not yet been included in a package snapshot. See Deployment  for details of how to work with snapshots.
  9. Enter a Start Date and an End Date for the rule (optional). If the End Date is earlier than the current date, the rule is marked with a flag (Grs auth-tool flag.gif ) to indicate that the rule is out of date.
  10. In the lower panel, fill in the When and Then rows.
    1. To add a Condition (When), click Add Condition and select from the list (for example, a condition for this scenario might be When the customer is a Gold member). The rule condition includes the name of the rule template from which the condition is derived.
    2. To add an Action (Then), click Add Action and select from the list (for example, an action for this scenario might be Increase the priority by 100). The rule action includes the name of the rule template from which the action is derived.
      3. Important
      The maximum limit of 6 segments (text plus variables) on Conditions or Actions in linear rules has been increased to 9 in release 8.5.303. An error message is displayed if this limit is breached.
    3. Insert values for the parameters into the table under the Condition and Action columns. Depending on how the parameters were configured by the rule template developer in GRDT, there may be constraints on the values that can be entered.
  11. Click Validate to validate the syntax of the linear rule. The Validate option appears in the drop-down located in the lower left side of panel.
  12. Click Save to save your changes.
    13. Important
    When you make any modifications to the body of a rule, you "lock" the rule, which prevents others from being able to make changes to the same rule at the same time. The unsaved icon will appear on the rule summary to alert you that you need to save your changes. For any other user, the locked icon appears on the rule summary and the Save and Cancel buttons are disabled. In addition, other users are unable to make changes to the rule because it is marked "read only".


When editing rules, be careful not to clear your browsing history or cookie data, as this might cause the rule to be stuck in a locked state. Unsaved changes could be lost.

Creating Rules Packages

Follow these steps to create a new rule package:

  1. Select the node in the business hierarchy to which this rule package will belong from the drop-down list. Rule packages can belong to any node in the hierachy from release 8.5.1. In releases before 8.5.1, you can only select the Tenant to which this rule package will belong.
    2. Important
    Package names must be unique across nodes or tenants.  Package names should follow a naming convention such as including the node/tenant name, or company name, in their package names to avoid conflict.
  2. In the Explorer Tree, select New Rules Package under the appropriate node or Solution. You must have appropriate permissions for this option to display.
  3. In the Details Panel, enter a name property for the new rule package.
    4. Important
    There are two name properties for a rule package: Package Name and Business Name.
    Package Name must conform to Java package naming conventions. Generally speaking, the package name should be in all lower case, can contain digits but must not start with a digit, and "." should be used as a separator, not spaces. For example, my.rules and myrules1 are both valid names, but My Rules and 1my.rules are not valid package names. Each organization should establish its own naming conventions to avoid name collision. Additionally, Java keywords must be avoided in package names. For example, my.package or new.rules are not valid package names. A list of Java keywords can be found here.
    Business Name allows you to provide a user-friendly name for the rule package, as it appears in the GRAT Explorer Tree. For example, Acme Rules is not a valid rule package name, but you could use acme as the Package Name and ACME Rules as the Business Name.
  4. Select which type of rule package you are creating. The drop-down list shows which types are already in the repository for the selected tenant. As you change the type, the list of templates for that type will be displayed.
  5. Enter a description for the rule package. The available rule templates (that were created for the node/Tenant and match the type selected in Step 4) will appear in the table. Templates prefixed with "(*)" are templates that were created in the Environment Tenant and can be used by all Tenants. Rule developers create rule templates and publish them to the rules repository by using the GRDT.
    6. Important
    The access permissions configured in Configuration Server can also affect which templates are displayed.
    Important
    GRAT users can select between multiple versions of templates, which are displayed on the enhanced Template Selection dialog along with version comments created by the template developer to help identify differences between the versions.  The number of versions of a template that are displayed is configured in Genesys Administrator.
  6. Select the template(s) you want to include and click Save.
  7. The new rule package will appear in the Explorer Tree. Expand the new rule package, and the following options (subject to the permissions set for your user ID) will appear under the rule package folder:
    • Split Test Configuration—Use this node to create rules that enable you to control how Split Testing applies to rule at the rule package level.
    • Business Calendars
    • Test Scenarios
    • Deploy Rules
    • Search
    You will also see the business structure nodes to which you have access permission.
  8. You can now create rules for your rule package.

Rule Authoring

Rule authoring is done through GRAT. This topic describes how to log into GRAT, gives some general information about its usage, and how to use it for creating decision tables, linear rules, and business calendars.

Levels

In the Genesys Rules Authoring Tool, there are three levels at which business rules can be created:

  • Rule Package (referred to as Global Rules)
  • Department
  • Process

Global rules enable you to specify rules that will apply to the entire solution. For example, they enable you to configure rules that classify or prioritize all tasks globally, instead of at a lower level of the business structure. Global rules are applied before any other rules.

This means that each rule phase (classification and prioritization) is triggered from within the relevant business process in the following sequence:

  1. Global rules
  2. Department rules
  3. Process rules

When the appropriate node is selected on the rule package tree, you can then select the Rules tab to view or edit the rules for that level of the business structure. Rules are presented in a list, with an associated phase. The order of the rules is relevant, because they will be evaluated, within a particular phase, in the same order as they appear. You can change the order of rules by clicking the up and down buttons. The logic of a particular rule can be expressed as either a linear rule or a decision table.

Any extended or custom attribute can be read or updated by business rule conditions or actions, respectively.

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.

Important
The business structure is defined in Configuration Manager or Genesys Administrator.

Rule Packages

Rule packages provide the following capabilities:

  • The ability to partition rules and facts so that they are small, well-defined, and apply only to a particular application or use. This makes them easier to debug and understand. The fact model is a description of the data. It contains field names and types which are grouped into tables/classes. Facts are input/output to rule execution and are instances of the tables/classes defined in the fact model.
  • The ability to isolate rule packages from one another when executing rules. This also improves performance because the Rules Engine has fewer candidates to examine during the evaluation.
  • The ability to update individual rule packages without affecting other deployed packages.
  • The ability to import and export an entire rule package containing the rule definitions, business calendars, and also the templates that the rule package is dependent on.
  • A rule package contains one or more rules plus the fact model that is needed to support the rules. You deploy rule packages individually to the Rules Engine.

|+DETAIL How to create a rules package|

Linear Rules

A linear rule is a business rule that has a set of conditions (when) and actions (then), and is used for a simple (linear) business case. A linear rule follows the following basic format: 

WHEN {condition} THEN {action}

For example: 

When a task is due in 1 to 8 hours, set the task's priority to 20.

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.

|+DETAIL How to create a linear rule|

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.

Important
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.

After you have created a decision table, you can create additional decision tables or linear rules, or deploy your rule package.

Defining a decision table is similar to defining a linear rule.

|+DETAIL How to create a decision table|

This page was last edited on June 30, 2016, at 09:42.
Comments or questions about this documentation? Contact us for support!