How do business rules work in our Oracle Service Cloud application?
The rules feature is quite powerful in allowing you to define conditions and actions to take on records within your Oracle Service Cloud application. You can set up rules to route new, incoming incidents as well as escalate existing records. Business rules can act on most of the record types within the Oracle Service Cloud database, including incidents, answers, contacts, organizations, chat sessions, and sales opportunities. In addition, rules can be applied to both new and existing records.
The basic format of an individual rule includes an IF section that defines the criteria that a record must meet and a THEN section that defines which actions are executed for that record. Conditions in the IF section of the rule are based on how certain fields are set for the record, such as "IF the incident.status equals Unresolved" or "IF the incident.source equals Ask a Question or Email".
The THEN part of the rule often includes actions that sets fields for the record or assigns the record to a group or individual or sends a notification to a group or individual.
A rule can also include an ELSE clause that allows you to define how to act on the record if the IF conditions are not met. This allows you to construct conditions and actions that support the phrase:
IF these conditions are met,
THEN do these actions on the record
ELSE (otherwise) do these actions on the record.
This answer is intended to provide an overview of the rules functionality. For comprehensive information regarding rules, refer to the Business Rules Management section in online documentation for the version your site is currently running. To access Oracle Service Cloud manuals and documentation online, refer to the Documentation for Oracle Service Cloud Products.
Types of Rules
Several rule types (listed below) are available to automate your business processes and ensure that records are handled consistently. Rulesets are created separately for the different types of records in your application. For example, you can create a ruleset for routing and escalating incidents. You can also create a ruleset for routing and escalating opportunities.
|Incident Rules are triggered when incidents are created or updated. You can use incident rules to notify staff when incidents are received from certain accounts, if you wish to automate an escalation, or to present end-users with SmartAssistant suggested solutions.
|Answer Rules are triggered when answers in the Answer Console are created or updated. You can use answer rules to notify your knowledge engineer when a new answer has been proposed or to notify your legal team when a finished answer is ready for their review.
|Contact Rules are triggered when contact records are created or updated. For example, you can use contact rules to automatically apply service level agreements (SLAs) or to set fields based on how the record is created or updated.
|Organization Rules are triggered when organization records are created or updated. For example, you can use Organization Rules to notify support staff or accounts receivable when an organization record is created or updated.
|Task Rules are triggered when a task is created or updated. Task rules can be used to notify staff members when a task is overdue.
|Opportunity Rules are triggered when a sales opportunity is created or updated. You can use opportunity rules to notify managers when a sales opportunity reaches a certain status in your sales cycle.
|Chat Rules are triggered when a new request for a chat session is received. For example, you can use chat session rules to route chat requests to a particular agent queue and to escalate the request to another queue if it is not answered in a specific amount of time.
|Offer Advisor Rules are triggered when contacts match the defined target rule.
You can configure a set of rules for each of these types of records, which is called a rulebase . Each rulebase works independently of the others since each rulebase applies to a specific type of record. That is, contact rules only apply to contact records and incident rules only apply to incident records.
Each time a record is created or updated, it is compared to the rulebase for that record type. If the record matches the IF conditions for the rule, the action is executed.
Edit and View Modes
Business rules are accessed from the Configuration > Site Configuration area and then selecting Rules.
Note that when selecting a rule type, you are given the option to view the active ruleset (View Active) or to Edit the rules. When you select View Active, you are taken to a read-only screen where you can review all currently configured rules that are working in your site for the record type that you select.
When you edit rules, you are actually working in a copy of the rulebase that you can choose to activate or abandon, depending on your modifications. Therefore, when you are in the edit mode of your rules, you can make changes to the copy of your rulebase, but those changes do not go into effect until you activate that copy of the rulebase. When working with a rulebase, the left-hand panel displays all states, rules, and functions configured in the rules module.
When configuring rules, you must define rule states for your records. A rule state represents a certain time or condition in the lifespan of a record, for example, at a high level answers might have a creation state, review state, and publish state.
Each state contains a set of rules that are applied when a record reaches that state. For example, a creation state includes the rules that are to be applied when a record is first created. The record is matched to the rules for the created/initial state and the appropriate actions are enacted. Actions that can be taken include transitioning the record to a different state, where it will begin matching a new set of rules, immediately or on the next update.
In general, each type of rulebase should have at least two states -- one for when the record is created (an initial rule state) and the other for existing records. Rules are generally set up so that when a record is created, it will be compared to the rules in the initial/created rule state and then a rule in that state will transition the record to an existing rule state.
With this approach, new records are evaluated and routed and then become an "existing" record. Within the existing rule state, there are frequently other rules that allow for escalations and notifications associated with updating the existing records.
You may find that you need to apply the same set of rules frequently under a variety of conditions within your overall ruleset. Functions allow you to define a set of rules and actions that are to be executed when invoked by a single rule. That is, from within a rule, you can call a function and that function consists of a set of rules. You can also call a function from a rule that is in a function.
Functions make it easier to manage sets of actions that are used in several different rules, by allowing you to define them only once and then invoke the function from separate rules. Once you create a function, it will be available as an action in your rules. Sets of escalation rules are frequently included in an escalation function.
Enabling Your Rules: Compile and Activate Options
When you choose the Edit option for a type of rulebase, if a copy of the rulebase doesn't exist, then a copy will be created when you first click Edit. If a copy of the rulebase already exists (because you have already been in Edit mode and did not activate or abandon the edited rules), when you click Edit, you will be taken to the existing copy. Either way, when you are in Edit mode, you are not actually editing the active, live set of rules. To commit the changes you have made while in Edit mode, you must compile and activate the edited rulebase.
Note: While in Edit mode, you can tell when the copy of the rulebase was created and by whom by viewing the lower section of the right frame. The top part of the right frame includes a chart that illustrates relationships between current rule states and functions. In the left frame, you can right click to add states, rules, or functions and the main panel displays a configuration screen where you specify the appropriate parameters for your rules.
The Compile button causes the Oracle Service Cloud application to verify the integrity of your current rules, that is, to ensure that there are no missing operators or values and that your rules can be executed as configured. Use the compile option when you want to check your progress during an overall edit session.
The Activate button both compiles and activates the new rulebase that you have been editing. This action verifies the integrity of your rules and makes your changes go into effect immediately. This action causes the application to replace your active rules with your newly compiled rulebase.