This chapter covers the following topics:
A business rule is a user-defined condition. When the condition is not met, the rule triggers a workflow process. The process is enforced by the business rule owner.
A business rule can be as simple as "A service request cannot be left open for more than two days." This rule can be defined according to an organization's needs or an agreement between its customers.
Example
Vision Corporation, a service organization, is eager to provide efficient customer service, so the Service Department Director for Vision Corporation defines a business rule based on the company's goal. This rule is that if a task with a high priority is open for four hours, then the task owner should be notified to proactively manage potential issues. Effective immediately, the director is the owner of this business rule as he is responsible for any future updates and necessary confirmation.
Additional examples include:
A service request is assigned within half an hour. Otherwise, the owner of this request receives a warning notification.
A task with a high priority is closed within two days. Otherwise, a manager investigates why it cannot be done within that time frame.
The Business Rule Monitor (BRM) provides a User Interface (UI) and functionality that an organization uses to proactively manage escalations. It consists of two components:
Business Rule Workbench: used to define a business rule.
Business Rule Monitor: the engine that monitors documents over time against the user-defined business rules.
The BRM module integrates with Oracle Workflow to provide possible action taken if the condition defined in the rules is not met.
Note: The functionality of BRM is not limited to only detect potential problems. It can also be used as a reminder of positive reinforcement, such as to remind employees of a company's annual events or an employee's birthday.
When defining your rules, you must also specify the workflow information for actions that can occur when the rule is violated. There are four seeded workflow processes:
Notification Only
An Oracle Workflow notification is sent. The person who receives this notification selects from the Value field in the Workflow Attributes window. Click the "..." button to display this attributes window.
Create a Task Only
An automated escalation task is created. This is generated through the seeded Automated Escalation Template Group for Task Manager (Service Request). The owner and assignee of this task select from the Value field in the Workflow Attributes window.
Notification and Create Task
In addition to the sent workflow notifications, an automated escalation task is also created. The owner and assignee of this task are specified in the Value field.
Escalated Object
An escalated document is created. The owner of this escalated document can be specified in the Value field. The selection in the Value field can be a document owner, the document owner's Human Resource manager, an escalation territory primary contact, or the business rule owner. If this value is not specified, it defaults to the business owner.
Note: If the unassigned option is selected in the Automated Escalation Notification Task Assignee Role field in the Workflow Attributes window, then the task that is created has no assignee, but it has an owner specified and there is no unassigned option in the List of Values for the task owner role field.
In addition to the Workflows which provide standard escalation activities, each of the seeded Workflow processes has its own Workflow attributes, which can be accessed in the Business Rule Workbench window. The value chosen for each attribute is saved as part of the Business Rule and allows you to control the behavior of the escalation activity for that rule.
Workflow attributes in the Business Rule Monitor seeded workflows are specific to the workflow process. The following table lists each seeded workflow process, the attributes it has, the meaning of that attribute, and possible values. Attributes are the same regardless of whether or not the Workflow is for a task, or a service request.
| Workflow Name | Attribute | Meaning | Possible Values |
|---|---|---|---|
| Send Notification | Automated Escalation Notification Role | Send the notification to the person who fulfills the role indicated by the value selected. |
|
| Create Task | Automated Escalation Notification Task Assignee Role | Assign the task to the person who fulfills the role indicated by the value selected. |
|
| Create Task | Automated Escalation Notification Task Owner Role | The task owned by the person who fulfills the role indicated by the value selected. |
|
| Create Task | Automated Escalation Task Template | The template that is used to create the task. | Any Task Template |
| Send Notification and Create Task | Automated Escalation Notification Role | Send the notification to the person who fulfills the role indicated by the value selected. |
|
| Send Notification and Create Task | Automated Escalation Notification Task Assignee Role | Assign the task to the person who fulfills the role indicated by the value selected. |
|
| Send Notification and Create Task | Automated Escalation Notification Task Owner Role | The task owned by the person who fulfills the role indicated by the value selected. |
|
| Send Notification and Create Task | Automated Escalation Task Template | The template that is used to create the task. | Any Task Template |
| Escalate Object | Automated Escalation Document Owner Role | The escalation document owned by the person who fulfills the role indicated by the value selected. |
|
A document owner can be of any resource type as well as an employee resource. Some examples of other types of document owners are: parties or partners and supplier contacts. Since the automated escalation can happen to the document owner of any resource type, the person who will receive the notifications is determined as follows:
The Document Owner is selected as the value in the workflow attributes.
If the document owner type is an employee resource, then the document owner will receive notifications.
If the document owner resource is of any other type, then the primary contact with the employee resource type in the escalation territory is used. If there is no resource that satisfies this criteria, then the primary contact with the employee resource type in the catch-all territory is used. Again, if there is no resource that satisfies this criteria, then the Business Rule Owner is used because the business rule owner is guaranteed to be an employee resource.
The Document Owner's HR Manager is selected as the value.
If the document owner is an employee resource, then the notification is sent to the HR manager of that resource. If there is no resource that satisfies this criteria, then the primary contact with the employee resource type in the escalation territory is used. Otherwise, the primary contact with the employee resource type in the catch-all territory is used, and then the Business Rule Owner is selected.
If the document owner resource is a group resource, then the notification is sent to the first employee resource within the resource group who has a manager. If there is no resource that satisfies this criteria, then the primary contact with the employee resource in the escalation territory is used. Otherwise, the notification is sent to the primary contact with the employee resource in the catch-all territory, and then the Business Rule Owner.
If the document owner resource is of any other type other than employee or group resources, then the same rule is used: the primary contact with the employee resource type in the escalation territory, then the primary contact with the employee resource type in the catch-all territory, and then the Business Rule Owner.
The Escalation Territory Primary Contact is selected as the value.
The notification is sent to the primary contact with employee resource in the escalation territory.
If there is no resource that satisfies this criteria, then the notification is sent to the primary contact with employee resource in the catch-all territory. Otherwise, the Business Rule Owner receives the notification.
The following suggestions are helpful when defining rules in the BRM:
The condition should not reflect an absolute state. Otherwise, the monitor will keep detecting the same objects and acting upon them; you may have repeated notifications sent.
Use reasonable check intervals. The check interval also determines the notification interval. So, if you check a rule every two minutes, notifications are sent every two minutes.
Take loop time into consideration. If the main scan cycle is set to run every ten minutes, then there is no point in setting the check frequency to two minutes.
Even in a simple rule, SQL syntax applies. You can use SQL functions, but you also have to use quotes around your character values. Also use IS NULL and IS NOT NULL instead of =NULL and <>NULL.
Verify that the view does what you intended for it to do. The simplest way to do this is to cut and paste the view definition from the Complex tab into a SQL+ session.
Check the performance of the view. Do a Select from your view. If it takes a long time to return the values, then ask a SQL expert for assistance.