Overview of Business Rule Designer

What are Business Rules?            

Technology has enabled us to automate mechanical tasks. Business Rules are server-side scripts that are specifically designed to seed intelligence into the system by providing certain conditions that, when met, trigger specific actions such as sending notifications and calling APIs. These rules are adaptable and can be customized to automate day-to-day tasks.

Business Rule Designer is an interface for creating and managing your Business Rules. It provides a platform for creating, editing, and manage your rules. The Business Rule Designer also includes a Rule Engine that helps you manage and execute business rules.

Open

Figure: Bird’s Eye View of Business Rule Designer

To better comprehend how business rules can be used to get better results, let's look at a few examples.

Benefits of using Business Rules

The effective management and automation of Business Rules provide several valuable benefits to organizations. The Business Rule Designer, has a super-intelligent Rule engine that can decrease costs, increase revenue, improve compliance, and provide better customer experiences.

Figure: Benefits of using Business Rules

Business Rule Configuration

A Business Rule is made up of three main components:

• Trigger

• Condition

• Action

When you create a Business Rule, you must define the trigger, and then set the conditions.  The action is performed automatically when the trigger and the condition is met.

Figure: Business Rule Framework

Trigger

A trigger lets you define when the Business Rule should execute. A trigger can be defined on the creation and on updating of a task. A trigger can also be defined using After or Async Business Rules.

Trigger Type – Create and Update

When the user creates a Business Rule, the user has the option to create the Business Rule,

Execution Mode

After and Async Business Rules

After: Use the After Business Rule when a field needs to be updated and displayed immediately after the user submits a record. The After Business Rule gets executed whenever the user submits a form and the data is saved in the database.

When selected, the After Business Rule will trigger once the Incident is created or updated. Also, the incident will be frozen, and no update will be allowed on the incident until the Business Rule is processed.

Async: The Async Business Rule is processed asynchronously and runs in the background. In the case of Async, the Incident will not be frozen, and the rule will run in the background. Running on background means that the user can proceed with other functionality and code will run on the background which will not impact the user while doing other transitions.

Async Business Rule is required when some tasks need to be performed in backend for updating some table data etc and the user need not know about. Async Business Rule runs in the background simultaneously with other processes.

When NOT to use After/Async (Examples)

Incorrect use of After Business Rule

Scenario: Fredrick, an analyst wants to update 100 Incident records simultaneously using a Business Rule.

As this operation would generally take a longer duration to complete, an end user/customer would not want to wait until this operation gets completed.

Incorrect use of Async Business Rule

Scenario: Fredrick wants to update the short description of an Incident using Business Rules.

To know more about how to configure Triggers, refer Business Rule Configuration for IM.

Difference between After and Async Business Rule

Let’s have a look at the differences between After and Async Business Rules with some examples.

Use Business Rules with Caution

Business Rules are intended to address common actions. Compared to what a developer can do by using form scripts, Business Rules have their limitations.

As a word of Caution, creating redundant and too many Business Rules can have a performance impact on your application. Summit recommends having regular checks and consolidating redundant Business Rules into a single rule whenever possible. In addition, Business Rules that are not being used should be removed to avoid redundancy.

Having too many or redundant Business Rules can have a negative impact on the SummitAI application as the system will need to compute and address all the Business Rules that have been configured before performing any action. Hence it is advised to use Business Rules in an efficient manner to get the best outcome of using them in your organization.

Condition

A condition is made up of a field, an operator, and a value. You can formulate complex conditions for rules that include several conditions by utilizing logical operators such as AND or OR operators.

You can use the condition builder to determine when the Business Rule actions should be executed. When a request arrives, there are two options the user can select: 

• Conditions based on criteria: Select this radio button to specify the conditions based on which the action would be executed.

• No Condition: Select this radio button if there are no conditions.

Grouping of Conditions

When there are multiple conditions which need to be computed together, these conditions can be grouped together in a Business Rule. This can be achieved by using the AND/OR conditions and by using the grouping functionality provided in the tool.

Here is an example scenario which shows how we can use Grouping of Conditions to achieve the best results:

Example

Scenario: Fredrick wants to auto close low priority Incidents which belong to the End user computing workgroup.

Solution:

Trigger: Here the trigger will be configured in the Incident Module in Async mode, and the Trigger type will be Scheduled

Condition:

Status = Resolved

AND Priority = P4

AND Impact = Low

OR {{Workgroup = Computing} AND {Impact = High}}

Figure: Example of grouped conditions

If this condition is to be written from left to right in normal code, it would appear as shown below.

Open

{Status = Resolved} AND {Priority = P4} AND {Impact = Low} OR ({Workgroup = Computing} AND Impact = High})

Business Rule follows BODMAS rule and processes the conditions in the Brackets (ON RIGHT) first and then left to right as shown below:

Figure: Business Rule Condition processing order

Once it has completed processing the conditions in the Brackets, then AND/OR conditions are processed. In this way we can have multiple conditions grouped to achieve the desired result. 

Action: The action will be to close the Incident if the above criteria is met. 

Fields

Based on the selected module, the fields related to the module are populated in the drop-down list from which you can select the required option. The supported Fields and Field types are as listed below:    

List of fields Supported:

Standard Attributes