Follow these steps to create a new decision table:
- 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.
- Click New Decision Table.
- In the Rule Summary, the ID field is populated automatically. It cannot be edited.
- Enter a Name for the decision table (for example, Status).
- Enter a brief Description for the rule (for example, Adjust the priority, depending upon the customer's status).
- 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).
- Select the Business Calendar to use with this rule (optional).
- 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 (
) to indicate that the rule
is out of date.
- 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.
ImportantBy 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.
- Add Conditions and Actions in the lower panel.
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.- Select one or more Conditions from the list (for example, a condition for this scenario might be named Customer's age is ...).
- Select one or more Actions from the list (for example, an action for this scenario might be named Increase priority by xxx).
- 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.
- Repeat Step c, adding more condition and action values.
- Re-order the rows as appropriate.
- Click Validate to validate the syntax of the linear rule.
- Click Save to save your changes.
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".Summary
In order for rules to be invoked by Genesys applications, you must deploy the rule package to one or more Genesys Rules Engines (or for Genesys Web Engagement, to the GWEB backend server). The deployment process (whether you choose to deploy immediately or to schedule the deployment for later) attempts to compile the rule package and informs you of the result via the Deployment Pending pop-up message. You can check on the status of your deployment by looking at the Deployment History tab, which shows the status Pending. When deployment is in pending status, you will not be able to cancel or undo it.
This process enables you to correct any errors before deployment. In addition, if you attempt a deployment that would duplicate either;
- An already scheduled deployment or;
- An attribute of an already scheduled deployment, such as;
- The same rule package
- For the same snapshot
- For the same destination server/cluster
an appropriate message is displayed. You can then either change the attributes of your deployment, or go to Deployment History and change/delete the scheduled deployment.
To use the deployment screen, you must have deploy permissions set up in Genesys Administrator.
To deploy a rule package:
- Select the Tenant to which the rule package belongs from the drop-down list.
- In the Explorer Tree, select the name of the rule package.
- Under the rule package, select Deploy Rules. (The number of rules as yet not included in a snapshot appears in parentheses.) The Details Panel contains two tabs:
- The Outstanding Deployments tab allows you to select from a list of snapshots of the package including the LATEST version of the package (if configured by an administrator), create a new snapshot, export a snapshot (as an XML file downloadable to the user’s local file system), delete a snapshot, deploy the rule package, schedule a deployment to occur at a future time, and show the source of the package. (Show Package Source displays the actual contents of the package snapshot you are deploying. The fact model, calendar definitions, and rule definitions will be coded into the rule language and displayed.)
Even if Run as Background Task is checked, the package will first be built and validated to ensure there are no errors. Once the validation is successful, the snapshot will be queued to a background task.
You cannot delete the LATEST snapshot, and you cannot delete a snapshot for which there is a scheduled deployment.- The Deployment History tab shows details about when the package snapshot was deployed in the past, and by whom. Failed deployments also appear in the list. In addition, the Deployment History displays scheduled deployments, and allows you to cancel or change the schedule of upcoming deployments.
To deploy the package immediately:
- Select the package snapshot, or the LATEST version (if available).
- Click Deploy Now in the Outstanding Deployments tab.
- Select the Location to which the package snapshot will be deployed. Locations can include application clusters configured in Genesys Administrator, or the GWEB backend server for Genesys Web Engagement.
- Enter some comments about the deployment (these will appear in the Deployment History).
- Click Deploy.
A message will be displayed indicating whether the deployment was successful.
To deploy the package later:
- Click Schedule Deployment in the Outstanding Deployments tab.
- Select the Location (the name of the Rules Engine application or application cluster, or the GWEB backend server for Genesys Web Engagement) to which the package snapshot will be deployed.
- Enter the date and time you would like the package snapshot to be deployed.
- Enter some comments about the deployment (these will appear in the Deployment History).
- Click Schedule.
A message will be displayed indicating whether the deployment was successfully scheduled.
If you wish to reschedule a previously scheduled deployment, or wish to cancel a scheduled deployment, you may do so from the Deployment History tab.
To refresh the display of a deployment history, click the Refresh button, or click in the relevant node in the Explorer Tree.
To display details of a deployment to a cluster:
If you are deploying to a cluster, you can now display a detailed report of the deployment, whether it succeeded or failed. This gives useful information on how a deployment has progressed: you can see, for example, whether a server connection was temporarily down at a critical moment, or whether a server timeout setting might need to be changed.
- Phase 1 - (Deploy) All GREs in the cluster are notified about the new rule package. Each GRE downloads the new rule package and compiles it.
- Phase 2 - (Commit) Once all GREs have successfully completed Phase 1, GRAT notifies each GRE to activate and commit the new rule package.
To show the report:
- Click on the Failed/Successful link in the Status column.
- The details of each deploy action to each server in the cluster are displayed, including:
- The GRE Server Name
- The server status
- The success or error message generated by the server
- The Phase 1 (and Phase 2) deployment times in seconds
New Features by Release
New in Release 8.5.001
Support for Conversation Manager Template and Rules Package
This release contains a new Conversation Manager template and a rules package that make it much easier and quicker for Conversation Manager customers to develop and implement their own solutions. The Conversation Manager Template provides a tighter integration between the Conversation Manager objects like Customer Profile, Service, State and Task and the Genesys Rules System, allowing you to move key business decisions into rules instead of application logic.
The template can be imported directly into GRAT and requires no modification in GRDT. Please see the Conversation Rules Template Guide for more information.
Support for Wildcards in Decision Tables
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/caveats for this solution.
- The wildcard values work only in decision tables.
- 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
This is ONE condition, and it will be excluded for that row if one or more of the fields contains a wildcard value.
The screenshot below shows the wildcard being used in a Decision Table.
- In DTR-112, the media type is not considered in evaluating the rule.
- In DTR-113, the Customer segment, media type and active service conditions are not considered. This rule catches any interactions not trapped by the rules above it, and directs them to the BS_General skill group.
See also GRAT Configuration Options.
Enhanced Rule Reporting
In this release, you can now configure a new option in GRE—include-disqualified-rules-in-response—to report disqualified rules (rules that did not fire), conditions that evaluated false and rule evaluation time back to the REST client invoking the rule evaluation request. Before 8.5.001, only the results of rules that fired were returned.
This feature is part of is part of a larger planned feature to enable Rule Simulation (what-if scenarios using real historical data).
See also GRAT Configuration Options.
iWD's Business Context Management Service (BCMS) Functionality Moves to GRE
Most of the BCMS functionality of intelligent Workload Distribution is now moved into the Genesys Rules Engine. As a result, iWD 8.5.0 users must install GRS 8.5.001 as a prerequisite.
Help Content Moves to the Cloud
The content of GRAT Help topics is now delivered into the user session directly from the Genesys documentation website at docs.genesys.com. Where such access is not possible, users can configure the location of this Help to a URL within their firewall. A new configuration option controls this. See GRAT Configuration Options.
Help for GRDT remains in WebHelp format.
New in Release 8.5.0
Deployment Enhancements
If you are deploying to a cluster, you can now display a detailed report of the deployment, whether it succeeded or failed. This gives useful information on how a deployment has progressed: you can see, for example, whether a server connection was temporarily down at a critical moment, or whether a server timeout setting might need to be changed. The Status column now displays a Failed/Successful link, which you can click to display the details of each deploy action to each server in the cluster. These details include:
- GRE Server Name
- Server status
- Success or error message generated by the server
- Phase 1 (and Phase 2) execution times in seconds
See Deploying Rules Package for more context.
Decision Table Enhancements
You can now easily reorder the rows within 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. A new configuration option (evaluate-decision-table-rows-top-down) allows the administrator to set the order of evaluation (top to bottom or bottom to top). See Settings in GRAT in GRS Configuration Options. See also Creating Decision Tables for more context.
Operational Parameter Performance Enhancements
A new caching mechanism is in place to enable better performance when using operational parameters within rules. Three new configuration options control this functionality:
- cache-operational-parameters
- parameter-cache-timeout
- clear-cache-on-disconnect
See Settings in GRE in GRS Configuration Options.
Repository Performance Enhancement for Oracle 11 users
For Oracle users, a performance enhancement is available that is enabled only when you create a new database repository when either initially installing, or migrating to, 8.5.0. For more detail, go to the Migration to 8.5.0 page.
Java runtime changes
GRAT requires the Java JDK during installation, but no longer requires it once it is deployed and running in an application server such as Tomcat, JBOSS or IBM WebSphere.
Single Sign-On
GRAT now participates in the Genesys Single Sign-On (SSO) framework where deployment takes place to a Genesys Engage cloud SSO environment. When GRAT is deployed into this environment, GRAT users will log in once to the portal. If they choose GRAT, they will bypass the GRAT login screen if they are still authenticated. Note that this feature does not apply for Genesys on-premise customers deploying GRS. Some additional configuration options have been implemented to support this feature. Go to Deploying GRAT in Genesys Administrator for more information.
Support for Internet Explorer 10 and 11
Discontinued support
In this release the following are no longer supported:
- Oracle 10
- Internet Explorer 7