Jump to: navigation, search

Creating Decision Tables

Decision tables can have a maximum of 30 columns.

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

    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.
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".
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.
The Pending Snapshot field indicates whether any snapshot of this rule has yet been created. See Deploying Rule Packages for information on snapshots.
This page was last edited on September 25, 2014, at 08:06.
Comments or questions about this documentation? Contact us for support!