Search

This answer is intended to provide an overview of the rules functionality. For additional information, refer to the Business Rules on the Agent Browser UI or the "Overview of Business Rules" section in the Online Help User Guide documentation. To access Oracle B2C Service manuals and documentation online, refer to the Documentation for Oracle B2C Service 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.
	Custom Object Rules are triggered when custom objects are created or updated. (Enhanced Business Rules only)
	Account Rules are triggered when staff accounts are created or updated. (Enhanced Business Rules only)
	Asset Rules are triggered when assets are created or updated.  (Enhanced Business Rules only)

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 these locations:

• Legacy Rules: Configuration > Site Configuration area and then selecting Rules
• Agent Browser UI: Rules can be found in the Navigation Set under Configuration.

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.

Rule States

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.

Functions

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.

Deploying / Activating your Rules

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 deploy or activate the edited rulebase.

Note: While in Edit mode in legacy rules, 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 Deploy button in Agent Browser UI will deploy the changes you've made to the rulebase. 

The Compile button causes the Oracle B2C Service 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.