Business Logic Configuration Phase Overview
Contents
The iWD business logic configuration phase is where iWD business context is introduced. This includes definition of departments and processes. This phase also includes the definition of business rules for use in task processing. After this phase, iWD is fully functional and can start processing tasks. The iWD system configuration phase requires knowledge of business context for tasks that will be handled by iWD. This includes business processes, service-level agreements (SLAs), and other factors that influence task-handling logic.
Departments and Processes
Departments represent organizational entities for which iWD will perform task prioritization and routing. Processes represent the business processes that are within those enterprise departments. In iWD, processes are always grouped within (associated with) a department. Departments and Processes allow for the definition of task-handling business rules that are specific to a department or process context.
Departments and Processes are created in iWD GAX Plugin and stored on Genesys Configuration Server. They are used by iWD Manager for task filtering and Genesys Rules System for managing rules.
Each department and process allows for the definition of a maximum of 5 custom attributes to a department/process in order to provide additional enterprise-specific context for reporting purposes.
Rules
Part of configuring the business logic for departments and processes in iWD is configuring and associating rules. All business rule authoring for iWD is done through the Genesys Rules Authoring Tool, which is a component of the Genesys Rules System. These rules define the task-handling business logic that is applicable to the departments, processes, or the entire system. Generally, a rule is represented by zero, one or more conditions and one or more actions. If there are no conditions for the rule, its actions will always be executed. If all of the conditions are true, all of the actions are executed. If any condition is not true, none of the actions are executed.
Rules are expressed in an easy-to-understand human language, such as:
If the task is due in 10 or more minutes, increase priority by 10.
The implementation details are hidden in rule templates, and users who configure business logic deal only with high-level logical expressions.
Rules can be defined in one of two ways:
- As a linear rule
- As a decision table.
Linear rules are intended for complex rules that have many conditions and/or actions. Each condition or action is represented by a single line in the rule.
Decision tables represent a more compact form of rule representation; however, they might not be as well suited to complex rules. In a decision table, multiple rules are grouped together, so that each condition or action is represented by a column in a table, and each row represents a rule. The number and type of conditions and actions (columns) is constant across all of the rules in the list.
Task Classification
Task classification does the following:
- Associates a task with a configured process.
- (Optionally) assign values to other task attributes, such as business value and due time.
Task-classification logic is expressed via business rules that can be defined for three different contexts:
- Package-level rules (also known as Global Rules)
- Department
- Process
If rules are defined for more than one context, they are evaluated in sequence, as previously listed. After a process has been assigned to a task, additional classification rules are evaluated that have been defined, first at the rule package or global level, then at the department level, and finally at the process level. The figure below shows an example of Task Classification.
A process must be assigned during the classification phase. It can be assigned in two places:
- At the global level
- At the department level.
(A department can be assigned at the global level and then, the rule evaluation can continue at the department level to actually select a process.)
.
Task Classification Using the “Capture Point is” Rule Condition
For more information about task classification, refer to Working with the iWD Business Process for IRD or Working with the iWD Business Process for Composer/ORS.
Task Prioritization
The primary purpose of task prioritization is dynamic priority calculation, where dynamic means that the task priority can be recalculated multiple times during the task’s life cycle. As with task classification, prioritization logic is expressed via rules.
Prioritization rules are initially applied immediately after classification rules and then reapplied after a specified reprioritization period. The reprioritization period is expressed in the same way as any other rule action.
Task Prioritization
If a reprioritization period is not set for a task during the prioritization phase in business rules, the IWD_reprioritizeDateTime attribute is set to Dec 31, 2030. Therefore, for all intents and purposes. the task will not undergo further reprioritization unless it is restarted.
The Standard Rules Template includes two rule conditions, Is first prioritization and Is reprioritization that should be used in prioritization rules to ensure that the reprioritization interval is set correctly, while avoiding any unnecessary immediate reprioritization of a task (that is, the first time prioritization rules are evaluated).
For example, suppose you have a task that, during the classification phase, gets an initial priority of 100. You wish to increase the priority by 15 every 2 hours, if the task is due in less than 24 hours. You want to do the first check 1 hour after the task is classified. You would set this up by using two different prioritization rules, configured in the order shown below. The example Rule 1—Is First Prioritization shows the first rule, which includes the Is first prioritization condition. The second rule, shown in Rule 2—Is Reprioritization, includes the Is reprioritization condition.
Rule 1—Is First Prioritization Example
Rule 2—Is Reprioritization Example
For more information about task prioritization, refer to the Working with IWD Business Process documentation.
Business Calendars
A business calendar is a set of configuration parameters that define working days and hours, as well as holidays that apply to the business. In its simplest form, the business calendar would consist of definitions for both a working week and working hours that apply to all working days.
A definition of a working week from Monday to Friday—in which each day starts at 9:00 AM and ends at 5:00 PM—is a classic example of a simple business calendar. If necessary, exceptions to the usual working schedule (public holidays, business-specific holidays, nonstandard working hours, and so on) can be added to the business calendar.
Business calendars can be used in iWD rules to perform date and time calculations that take into account the working schedule of the business. Business calendars can either be assigned to a rule itself, or can be assigned in a rule action. In either case, the business calendar must be assigned before other rules that use the business calendar can be evaluated.
Business Calendar Example
