Loading

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.

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.

Example Use Cases

Let's explore the following use cases.

S.No.	Use Case User Persona: Analyst	Solution
1	William is an analyst who wants a new Incident to be auto assigned to the Server team when the Symptom contains the word ‘Server’ and the Priority is P1.	This can be achieved by configuring a Business Rule that triggers automatically for a new Incident where Symptom contains the word ‘Server’ & Priority is P1, the Workgroup will be auto updated to Server Team.
2	Sam is an analyst who wants to notify the head of Workgroup server team whenever there is an update to a ticket wherein the Category is ‘Server’ and Priority is ‘P1’.	This can be achieved using a Business Rule to set up notifications to be triggered whenever there is an update to an Incident to change the Category to ‘Server’ and Priority to ‘P1’.
3	The analyst Sam wants to auto-resolve low-priority open incidents awaiting end user input as the Pending Reason that belong to the ‘End user Computing’ Workgroup.	This can be configured using a Business Rule to auto-resolve low-priority incidents that belong to ‘End user Computing’ Workgroup where Pending Reason is ‘awaiting end user input’ and Incident status is ‘Open’.

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,

Create: When a user Configures a Business Rule with the Trigger type as On create, the rule will trigger immediately once the ticket is created.

Update: When a user Configures a Business Rule with the Trigger type as On Update, the rule will only be triggered when a user updates any fields or if the conditions are matched. (In this case the Business Rule will not trigger on creation of a new Incident even if the condition is matched).

Example

Create

Ryan is an end-user who creates an incident where the Tenant is ‘IT’, Symptom is ‘Laptop Not Working’, and the Description is ‘Issues in rebooting Laptop’. Once Ryan has created the incident, the Business Rule will automatically trigger.

Update

Ryan is an end-user who creates an incident where the Tenant is ‘IT’, Symptom is ‘Laptop Not Working’. In this case if when the incident gets assigned to an Analyst Maxwell. Once Maxwell updates the incident and the condition is matched, only then the Business Rule will trigger.

Figure: Example of a trigger On Create and On Update

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.

Example Use Cases

When to Use After & Async? (Examples)

After - Scenario 1

The end-user Ryan logs an Incident where a Business Rule has been configured in After. The Rule automatically updates Category as ‘Laptop’ and Workgroup as ‘Hardware Team’ if the Symptom contains the word ‘Laptop’. When this is configured in After, the Business Rule auto-updates fields and the page will get frozen till the update is carried out as shown in the below infographic.

Figure: Example of Business Rule in After

Scenario 2

Maxwell an analyst, has created a Business Rule which triggers After creating an Incident to perform an action to update certain fields once the conditions are matched.

In this case the Business Rule executes immediately After we click submit. The Record gets frozen until the Business Rule execution is complete, and the Analyst/Caller will not be able to update the record until the record is unlocked.

Figure: illustration of After Business Rule

Async - Scenario 1

Fredrick an Analyst needs to update an Incident with a Business Rule Configured in After to Notify the Head of IT & Server Team when there is a P1 Incident for Server Category. In this case the page does not get frozen, and the recipients get notified in the background.

Figure: Example of Business Rule in Async

Scenario 2

Maxwell has created a Business Rule which executes in Async when an Incident record is created or updated to perform an Action to Notify Recipients.

In this case, Business Rule executes in Sync with the record submission. The Record is not frozen in this case. Analyst/Caller will be able to update the record during the execution of Business Rule.

Figure: illustration of Async Business Rule

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.

Right	This task should Ideally be performed in Async Business Rule as we give the control to the user, but action is performed at the back end. This can be done for non-critical tasks such as for sending notifications and Calculating the SLA.
Wrong	If Fredrick has configured such a Business Rule in After, then the users must wait till updates on 100 records are completed before they can resume working on the record. Hence this is not an ideal use of this Rule.

Incorrect use of Async Business Rule

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

Right

This task should Ideally be performed using After Business Rule. Hence if the users are trying to update the short description, the control will be taken away from the user and the action will be performed, post which the control will be transferred back to the user. This will help in avoiding multiple entries in the database and ensure that all the users are seeing the same short description at once.

Wrong

If Fredrick performs this Business Rule in Async, the changes will happen asynchronously on every user’s machine. So, while a user might have already updated the short description on their machine, it might appear differently on another user’s machine.

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.

After Business Rule	Async Business Rule
Rules are executed synchronously.	Rules are executed asynchronously.
The After Business Rule is used when some fields need to be updated and displayed to the user immediately after user submits the record.	Async Business Rule is required when some tasks are to be performed in backend for updating some other table data etc and user need not know about that.
Freezes the record and restricts any changes to be performed.	Does not freeze the record and performs the actions in back-end.
Example: 1. To update an assignment group or work group in an Incident. 2. To update a short description of an Incident.	Example: 1. To create an event & send notification. User changes some field, based on that an event must be created, and notification sent to user. 2. To Calculate the SLA.3. For updating multiple records simultaneously, advised to use Async BR.

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.

Figure: Condition Builder

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.

{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

Field_Name	Field_Key	Field_Type	Field_Data_Type	Notification_API_Key
Incident ID	INCIDENT_NO	number	integer	INCIDENT_NO
Major Incident	MAJOR_INCIDENT	checkbox	integer	MAJOR_INCIDENT
Source	SOURCE	dropdown	string	SOURCE
Scheduled Incidents	SCHEDULED_INCIDENTS	checkbox	string	SCHEDULED_INCIDENTS
Has Attachment	HAS_ATTACHMENT	checkbox	bool	HAS_ATTACHMENT
Response SLA Violation	RESPONSE_SLA_VIOLATION	checkbox	bool	RESPONSE_SLA_VIOLATION
Resolution SLA Violation	RESOLUTION_SLA_VIOLATION	checkbox	bool	RESOLUTION_SLA_VIOLATION
Response SLA	RESPONSE_SLA	singleselection	string	RESPONSE_SLA
Resolution SLA	RESOLUTION_SLA	singleselection	string	RESOLUTION_SLA
CSAT Rating	CSAT_RATING	number	float	CSAT_RATING
Manual Escalation	MANUAL_ESCALATION	checkbox	bool	MANUAL_ESCALATION
Manual Escalation Level	MANUAL_ESCALATION_LEVEL	dropdown	string	MANUAL_ESCALATION_LEVEL
Auto Escalation	AUTO_ESCALATION	checkbox	bool	AUTO_ESCALATION
Auto Escalation Level	AUTO_ESCALATION_LEVEL	dropdown	string	AUTO_ESCALATION_LEVEL
Previous Workgroup / Assigned Workgroup	PREVIOUS_WORKGROUP	dropdown	integer	PREVIOUS_WORKGROUP
Previous Analyst / Assigned To	PREVIOUS_ASSIGNED_TO	dropdown	integer	PREVIOUS_ASSIGNED_TO
Previous Status	PREVIOUS_STATUS	dropdown	string	PREVIOUS_STATUS
Previous Category	PREVIOUS_CATEGORY	treeview	integer	PREVIOUS_CATEGORY
Previous Classification	PREVIOUS_CLASSIFICATION	treeview	integer	PREVIOUS_CLASSIFICATION
Previous Impact	PREVIOUS_IMPACT	dropdown	integer	PREVIOUS_IMPACT
Previous Urgency	PREVIOUS_URGENCY	dropdown	integer	PREVIOUS_URGENCY
Previous Priority	PREVIOUS_PRIORITY	dropdown	integer	PREVIOUS_PRIORITY
Previous SLA Service Window	PREVIOUS_SLA_SERVICE_WINDOW	dropdown	integer	PREVIOUS_SLA_SERVICE_WINDOW
Previous Pending Reason	PREVIOUS_PENDING_REASON	dropdown	integer	PREVIOUS_PENDING_REASON
Previous Closure Code	PREVIOUS_CLOSURE_CODE	dropdown	integer	PREVIOUS_CLOSURE_CODE
Previous Resolution Code	PREVIOUS_RESOLUTION_CODE	dropdown	integer	PREVIOUS_RESOLUTIONCODE
Previous Closure Category	PREVIOUS_CLOSURE_CATEGORY	treeview	integer	PREVIOUS_CLOSURE_CATEGORY
Previous Major Incident	PREVIOUS_MAJOR_INCIDENT	checkbox	integer	PREVIOUS_MAJOR_INCIDENT
Previous Source	PREVIOUS_SOURCE	dropdown	string	PREVIOUS_SOURCE
Previous Scheduled Incidents	PREVIOUS_SCHEDULED_INCIDENTS	checkbox	string	PREVIOUS_SCHEDULED_INCIDENTS
Previous Medium	PREVIOUS_MEDIUM	dropdown	string	PREVIOUS_MEDIUM
Previous Description	PREVIOUS_DESCRIPTION	textarea	string	PREVIOUS_DESCRIPTION
Previous Solution	PREVIOUS_SOLUTION	textarea	string	PREVIOUS_SOLUTION
Previous Symptom	PREVIOUS_SYMPTOM	text	string	PREVIOUS_SYMPTOM
Previous Secondary Analyst	PREVIOUS_SECONDARY_ANALYST	dropdown	integer	PREVIOUS_SECONDARY_ANALYST
Previous Sub Workgroup	PREVIOUS_SUB_WORKGROUP	dropdown	integer	PREVIOUS_SUB_WORKGROUP

Date Attributes

Field_Name	Field_Key	Field_Type	Field_Data_Type	Notification_API_Key
Log Time	LOG_TIME	date	date	LOGTIME
Updated Time	UPDATED_TIME	date	date	LAST_UPDATED
Closed Date	CLOSED_DATE	date	date	CLOSED_DATE
Updated Since (in Days)	UPDATED_SINCE	number	integer	UPDATED_SINCE
Pending For (in Days)	PENDING_FOR	number	integer	PENDING_FOR
Resolution Deadline Time	RESOLUTION_DEADLINE	date	date	RESOLUTION_DEADLINE
Resolution Time	RESOLUTION_TIME	date	date	RESOLUTION_TIME
Response Deadline Time	RESPONSE_DEADLINE	date	date	RESPONSE_DEADLINE
Response Time	RESPONSE_TIME	date	date	RESPONSE_TIME
Scheduled Date Time	SCHEDULED_DATE_TIME	date	date	SCHEDULEDATE
Target Completion Date	TARGET_COMPLETION_DATE	date	date	TARGET_COMPLETION_DATE
Current Time	CURRENT_TIME	date	date	CURRENT_TIME
Previous Log Time	PREVIOUS_LOG_TIME	date	date	PREVIOUS_LOGTIME
Previous Updated Time	PREVIOUS_UPDATED_TIME	date	date	PREVIOUS_LAST_UPDATED
Previous Resolution Deadline Time	PREVIOUS_RESOLUTION_DEADLINE	date	date	PREVIOUS_RESOLUTION_DEADLINE
Previous Resolution Time	PREVIOUS_RESOLUTION_TIME	date	date	PREVIOUS_RESOLUTION_TIME
Previous Response Deadline Time	PREVIOUS_RESPONSE_DEADLINE	date	date	PREVIOUS_RESPONSE_DEADLINE
Previous Response Time	PREVIOUS_RESPONSE_TIME	date	date	PREVIOUS_RESPONSE_TIME
Previous Scheduled Date Time	PREVIOUS_SCHEDULED_DATE_TIME	date	date	PREVIOUS_SCHEDULEDATE
Previous Target Completion Date	PREVIOUS_TARGET_COMPLETION_DATE	date	date	PREVIOUS_TARGET_COMPLETION_DATE

User Attributes

Field_Name	Field_Key	Field_Type	Field_Data_Type	Notification_API_Key
Username/Caller	CALLER	user_search	integer	CALLER
Logged By	LOGGED_BY	user_search	integer	LOGGED_BY
User Type	USER_TYPE	dropdown	integer	USER_TYPE
Customer	CUSTOMER	user_search	integer	CUSTOMER
Location	LOCATION	user_search	integer	LOCATION
Caller Location	CALLER_LOCATION	user_search	integer	CALLER_LOCATION
Join Date	JOIN_DATE	date	integer	JOIN_DATE
Time Zone	TIME_ZONE	dropdown	integer	TIME_ZONE
User Designation	USER_DESIGNATION	dropdown	integer	USER_DESIGNATION
Approval Required	USER_LEVEL	dropdown	integer	USER_LEVEL
Previous Username/Caller	PREVIOUS_CALLER	user_search	integer	PREVIOUS_CALLER
Previous User Type	PREVIOUS_USER_TYPE	dropdown	integer	PREVIOUS_USER_TYPE
Previous Customer	PREVIOUS_CUSTOMER	user_search	integer	PREVIOUS_CUSTOMER
Previous Location	PREVIOUS_LOCATION	user_search	integer	PREVIOUS_LOCATION
Previous Caller Location	PREVIOUS_CALLER_LOCATION	user_search	integer	PREVIOUS_CALLER_LOCATION

Operator

Based on the selected field value, the operators are displayed. Select the required operator from the drop-down list.

List of Supported Operators

List of Operators Supported

Operator_Id	Operator Value
1	=
2	!=
3	>=
4	<=
5	>
6	<
7	IN
8	NOT IN
9	Between
10	Contains
11	Today
12	Yesterday
13	Tomorrow
14	This Week
15	Last Week
16	Next Week
17	This Month
18	Last Month
19	Next Month
20	Last 3 Months
21	Last 6 Months
22	Last 9 Months
23	Last 12 Months
24	Last Quarter
25	Last Two Quarter
26	This Quarter
27	Next Quarter
28	Last year

Operator Examples

When the Data Type is String.

In this example the Symptom is the field that is created in the Form Designer that is created using the Textbox control, hence the Operator field will show the options related to a Textbox. The user can select whether the Symptom Field Contains or Does Not Contain a particular String value.

Figure: Example for String

When the Data Type is Date.

When we select the Data Type as Log Time (which is a Date type), then the operators loaded will be related to the Date Field. The user can select any of the following values related to the Log Time as shown below:

Figure: Date Example

Figure: Log Time Operators Example.

When the user selects an Operator such as On or Before or Between, then the Value field loaded will be of table selection type which gives the user an option to select the Date from a table as shown below.

Figure: Date Table

Numeric Value

If the user has selected the Field as Pending for (in Days), then the user can enter any value in the Value field and the operators loaded will be as shown below:

Figure: Pending For (In days) example

When the Data Type is Textbox / Text Area:

Consider the example where the user has selected the Description field under the Conditions, then the Operators loaded will be related to the Textbox values.

Figure: Textbox Example

When Data Type is Numeric

The user can choose a Numeric Data type in the Field section, based on which the Operators will be loaded. For example, when the user selects a value for cost or price, then the operators loaded are as shown below:

Figure: Price Example

You can select other an operator such as Between to select the price between two different prices.

Figure: Between operator Example.

Similarly, the different operators that can be used are as shown below:

Figure: Cost Operator Example

Value

Based on the selected Field type and Operator the options are populated in the Value field.

The value field can be one of the following four types:

Date
Dropdown
Numeric
String

Examples

Date

When the Field is Log Time and the Operator is EQUAL TO, then the Value field will be of Date type since the field selected is of Date Type.

Similarly on selecting the different operators the Value field will subsequently change to accommodate the operator selected such as for Between and Is Empty etc. as shown in the below graphic.

Figure: Date Log Time example

Dropdown

When the Field selected is Priority then you will have the below four options (in infographic) as operators and the Value field displayed will be of Dropdown Type.

When IN / NOT IN is selected, the value field allows the selection of multiple values in the field such as ‘P1’, ‘P2’ etc.

Figure: Dropdown Examples

Numeric
When the Field selected is of Numeric type such as Cost then the Value field will be of Numeric type where the user can enter Numeric values as shown below:

Figure: Numeric Value Example

String

When the Field selected is of String type such as Description, then the Value field will be of String type.

Figure: String Value Example

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

Action

The Action is performed automatically once the condition is met. You can define Business Rules with only an action and no condition.

Business Rule Actions are a configurable way to:

Update fields
Send out Notifications.
Run APIs.

Note

A single action or a combination of actions can be executed using Actions.

Update Fields

As shown below, the first type of Action is to update the fields and the values which can be updated after the trigger and condition are set:

Figure: Example of action to Update Fields

List of supported Fields

Field_Name	Field_Key	Field_Type	Field_Data_Type	Notification_API_Key
Workgroup / Assigned Workgroup	WORKGROUP	dropdown	integer	WORKGROUP
Analyst / Assigned To	ASSIGNED_TO	dropdown	integer	ASSIGNED_TO
Status	STATUS	dropdown	string	STATUS
Category	CATEGORY	treeview	integer	CATEGORY
Classification	CLASSIFICATION	treeview	integer	CLASSIFICATION
Impact	IMPACT	dropdown	integer	IMPACT
Urgency	URGENCY	dropdown	integer	URGENCY
Priority	PRIORITY	dropdown	integer	PRIORITY
SLA Service Window	SLA_SERVICE_WINDOW	dropdown	integer	SLA_SERVICE_WINDOW
Pending Reason	PENDING_REASON	dropdown	integer	PENDING_REASON
Closure Code	CLOSURE_CODE	dropdown	integer	CLOSURE_CODE
Resolution Code	RESOLUTION_CODE	dropdown	integer	RESOLUTIONCODE
Closure Category	CLOSURE_CATEGORY	treeview	integer	CLOSURE_CATEGORY
Medium	MEDIUM	dropdown	string	MEDIUM
Description	DESCRIPTION	textarea	string	DESCRIPTION
Solution	SOLUTION	textarea	string	SOLUTION
Symptom	SYMPTOM	text	string	SYMPTOM
Secondary Analyst	SECONDARY_ANALYST	dropdown	integer	SECONDARY_ANALYST
Sub Workgroup	SUB_WORKGROUP	dropdown	integer	SUB_WORKGROUP
Scheduled Date Time	SCHEDULED_DATE_TIME	date	date	SCHEDULEDATE
Target Completion Date	TARGET_COMPLETION_DATE	date	date	TARGET_COMPLETION_DATE
Cancellation Remarks	CANCELLATION_REMARKS	textarea	string	CANCELLATION_REMARKS
Response SLA Violation Reason	RESPONSE_SLA_REASON	text	string	RESPONSE_SLA_REASON
Resolution SLA Violation Reason	RESOLUTION_SLA_REASON	text	string	RESOLUTION_SLA_REASON
Incident Closing Mode	INCIDENT_CLOSING_MODE	dropdown	string	INCIDENT_CLOSING_MODE
Auto Closing Days	AUTO_CLOSING_DAYS	number	string	AUTO_CLOSING_DAYS

Note

Based on the module selected by the user, the relevant standard fields belonging to that module will appear in the Update Fields section.

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

Value

Based on the selected Field type the Values field gets auto populated.

Update Action Type

Update values first time: If selected, will update the fields only for the first time when the record is updated.

Example Use Case

Example

S.No.

Use Case

User Persona: Analyst

Solution

1

Sam wants to have a business rule that sets the category of an incident based on its description. Sam wants to update the category field on the incident record only for the first time when the incident is created.

Update values every time: If selected, will update the fields every time when the record is updated.

This can be achieved by creating a new business rule and selecting the appropriate trigger for the rule and selecting Update Values first time. For example, you might choose to trigger the rule when a new incident is created. Next, Sam needs to add a condition to check the description field on the incident record. For example, Sam can add a condition to check if the description contains certain keywords related to the category. If the condition matches, the category field on the incident record will get updated to the desired value.

Update values every time: If selected, will update the fields every time when the record is updated.

Example Use Case

Example

S.No.	Use CaseUser Persona: Analyst	Solution
1	William wants to have a business rule that updates the status of an incident based on its progress. William wants to update the status field on the incident record every time a task related to the incident is completed.	This can be achieved in Business Rule Designer by creating a new rule and selecting the appropriate entity and trigger for the rule. In this case William can choose to trigger the rule Every time when a related task is updated or completed on an incident record. Next, William will need to add a condition to check the progress of the incident. For example, he might add a condition to check if all related tasks have been completed. If the condition is true, the status field on the incident record will be updated as desired.

Note:

The Update Action Type field displayed only when the Trigger Type is selected as Update.
There are few mandatory fields based on status value selection. Based on the selected status value the following mandatory fields are displayed.

Override Values

If the Override Values = YES, then the values defined for the field in the Business Rule will override the values set for that field in the record.

If the Override Values = NO, then the values defined for the field in the Business Rule will be applied only if the value is not set (meaning empty) for that field in the record. As stated otherwise, if there is a value already available for a particular field in the record, then the Business Rule Value will not be applied.

Notifications

Under this tab, you can configure the notification templates for the business rule. You can create new notification template or use the existing notification template to send a notification to users.

Out of the Box Notifications

Out of the box notifications are notifications that are included in the default notification settings for a device or app. These notifications may include new messages, updates, or alerts.

Custom Notifications

Types of Recipients

Group	Members	Description
By Caller Group	Caller Caller's cc book Caller's Customer SPOC Caller's Line Manager Caller's Reporting Manager	Caller - Select User who called to raise the ticket. Caller’s cc book - Add the caller’s cc list. Caller’s Customer SPOC – The point of contact for the caller. Caller’s Line Manager - Line Manager of the user. Caller’s Reporting Manager - Reporting manager of the user.
By Analyst Group	Analyst Incident Vendor SPOC Incident Workgroup Incident Workgroup -Additional Owners Incident Workgroup Owner	Analyst – Analyst who is working on the ticket. Incident Vendor SPOC – The point of contact on the vendor side. Incident Workgroup – The Incident workgroup members who are part of the team. Incident Workgroup – Any additional owners/stakeholders who need to be informed. Incident Workgroup Owner – The owner of the Incident Workgroup.
By Designation	Search and select the required Designations.	By selecting this option, you can search a recipient by searching with the Designation of the required user.
By Workgroup	Search and select the required Workgroups.	By selecting this option, you can search a recipient by the required Workgroup.
By User Type	Search and select the required User Types	You can search a user by the User Type such as a VIP User.
By Customer	Search and select the required Customers.	You can select this option if you would like to search by and notify the Customer.
Custom E-mail ID	Type in required e-mail id.	You can add the email id of the recipient manually using this option.

You can configure the following notification types(mediums):

E-mail Notification
SMS Notification

Figure: Example of action to send SMS/Email Notifications

E- Mail Notification

Email notifications are a way to keep the recipients updated on the progress of your projects through emails. You can choose an email template and set rules to receive email notifications for events as shown in the below infographic.

Figure: Email Template Notification

To know more about how to create an Email notification, refer Business Rule Configuration for IM.

SMS Notification

You can also create SMS Notifications by selecting the SMS option under Medium.

To create an SMS notification, refer Business Rule Configuration for IM.

API

API stands for application programming interface. It is a set of protocols and tools that allow software to interact with other software. This can include anything from retrieving data to manipulating or controlling software.

The below infographic shows how the user can configure and run a new API once a particular trigger and condition are set.

Figure: Illustration of action to configure a new API

To know more about adding API, refer Business Rule Configuration for IM.

Business Rule Designer Use Cases:

Business Rule Designer Use Cases

1. Send an email notification based on poor CSAT rating

Scenario: Ryan wants to send email notification to the Analyst & Incident Workgroup Owner working on the Incident based on poor CSAT rating.

Solution: Ryan can achieve this by configuring a Business Rule in the Incident module in Async mode. Here the Business Rule will be triggered based on the condition when the CSAT rating is equal to 1, as shown in the below Images.

Trigger:

Module: Incident
When: Async
Trigger Type: Update

Figure: Example of Trigger configuration

Condition:

CSAT Rating = 1

Figure: Example of Condition

Action:

To send a SAD CSAT Notification Email to Analyst and Incident Workgroup Owner

Figure: Action to Send SAD CSAT Rating Notification

2. Call an API to create a ticket in Microsoft Vendor Portal

Scenario: Fredrick, an analyst wants to call an API to create a record in Microsoft Vendor Portal when there is any ticket for Microsoft Category.

Solution:

Trigger: Fredrick will update the trigger in Incident module in Async on Creation of an Incident.

Condition: The condition will be set to when the Category/Workgroup will be selected as ‘Microsoft’

Action: The action will be to call an API and create a record in Microsoft Vendor Portal when there is an Incident for Microsoft Apps Category as shown in the below Image.

Figure: Example of an API to create a ticket in Microsoft Vendor Portal

3. Auto Resolve Incidents which are not updated for more than 6 months using Scheduler based Business Rules

Scenario: Fredrick, an analyst wants to Auto-resolve Incidents which are pending and have not been updated for more than 6 months.

Figure: Scheduler Based Business Rules

Solution: Fredrick can achieve this task by creating a Business Rule in Async mode.

Trigger: Here the trigger will be set in Incident module in Async mode and Fredrick can schedule when the Business Rule should be executed. (E.g.: The Incidents to be resolved should be checked every Monday at 7:00 am. This can be achieved using the scheduler option)

Condition:

Updated since (in Days) > = 180
AND Status = Pending
AND Pending Reason = User Response Awaited

Update Action:

Status = Resolved

Figure: Action to update the fields

The Incidents which are pending and open for more than 6 months will be resolved with the below comments and Resolution Code:

Figure: Action to update the fields

4. Send Scheduled Notifications if the Incidents assigned to them are in Pending state and not updated since more than 5 days.

Scenario: Sam, an Incident Management lead wants to send scheduled notifications to analysts if the Incidents assigned to them are not updated since more than 5 days.

Figure: Scheduled Notifications for Incidents not updated since more than 5 days

Trigger: Here the trigger will be set in Incident module in Async mode and Sam can schedule when the notifications should be sent out to the analysts.

Condition:

Status = Pending
AND Pending For = 5 days
AND Updated Since > 5 days

Figure: Example Condition

Action:

To send reminder notifications email to Analysts and Incident Workgroup if the Incidents assigned to them are pending & not updated for more than 5 days.

Figure: Example of action to send reminder notifications

5. Close the P1 Incidents manually when the workgroup is Security, Server, or Network

Scenario: Fredrick, an analyst wants to ensure that P1 Incidents are manually closed when the workgroup is either Security, Server, or Network.

Solution:

Trigger: Here the trigger will be set in Incident module in After mode and the Trigger Type should be On Update as the Business Rule should get triggered when the status is set to resolved along with the other conditions.

Condition:

Priority = P1
AND Status = Resolved
AND Workgroup / Assigned Workgroup IN {Network Support L2 OR Security Team OR Server Support}

Action:

The Action would be to resolve the ticket and Update Fields as shown below:

Figure: Example of action to update the fields

Figure: example of action to update the fields

6. SLA Service Window Should be selected based on the CI but Priority should be based on the Urgency & Impact

Scenario: Sam, an analyst wants to make sure that while creating or updating an Incident, the Priority should be based on urgency and impact and the SLA window should be selected based on the CI.

Solution: Sam can configure the SLA Matrix by CI option to define the SLA Service Window based on CI. However, he must define the priority in this configuration because it is mandatory. But the requirement is that priority should not be based on CI, it should be based on Urgency & Impact.

Using Business Rule Designer, Sam can define the priority which is based on urgency and impact as shown below:

a. Create After/Async (Based on customer requirement) type on Create/Update trigger.

Figure: Trigger Type as Create/Update

b. Define the condition as Impact and Urgency as shown below:

Figure: Example Condition

c. Define the Actions in the update fields section and priority values as per the matrix.

Likewise, Sam will need to create the Business Rules as per the matrix that the customer wants to update priority with. (So basically, we can define the priority matrix configuration in Business Rule Designer to achieve these requirements.)

7. Send Auto Resolve notification after 2 days once the Incident has been resolved.

Scenario: Fredrick wants to send an automatic notification to end users to let them know that the Incident has been in resolved state for more than 2 days and will get auto closed.

Solution:

Trigger: Fredrick can configure this as a Business Rule on the Incident Module in Async mode. The trigger type will be Scheduled.

Condition:

Current Time ‘is more than’ ‘2’ Days 'After’ the “Resolution Time”.

AND Status = Resolved

Figure: Condition Example

Action: To send the auto resolve notification to caller after 2 days.

Figure: Action to Auto Resolve Notification After 2 days

8. Other Business Rule examples:

There are different workgroups – Tier 1, Tier 2, Tier 3, Lead Team, Accounting Team, Security Team, Database Team, Release Engineering Team

Tier 1 or Tier 2 team members navigate to ‘Log Incident for User’ screen > Update the details and set the Workgroup as Tier 3

Tier 3 team member (Analyst) updates a custom attribute (multi-valued dropdown) which has 3 values – Lead Approval, Accounting Approval, Security Approval

If Tier 3 selects all the 3 checkboxes in the above multi-valued dropdown, then first Workgroup should change to Lead Team. Below listed are all the permutations and combinations of Business Rules you can configure for such a scenario.

BR 1:
- Condition:
  - If Workgroup = Tier 3 & Approval Required = Lead, Accounting, Security
- Action:
  - Set Workgroup = Lead

BR 2:
- Condition:
  - If Workgroup = Tier 3 & Approval Required = Accounting, Security
- Action:
  - Set Workgroup = Accounting

BR 3:
- Condition:
  - If Workgroup = Tier 3 & Approval Required = Security
- Action:
  - Set Workgroup = Security

BR 4:
- Condition:
  - If Workgroup = Lead & Lead Approval = Yes
- Action:
  - Set Workgroup = Accounting

BR 5:
- Condition:
  - If Workgroup = Lead & Lead Approval = No
- Action:
  - Set Workgroup = Tier 3

BR 6:
- Condition:
  - If Workgroup = Accounting & Accounting Approval = YesAction:
  - Set Workgroup = Security

BR 7:
- Condition:
  - If Workgroup = Accounting & Accounting Approval = No
- Action:
  - Set Workgroup = Tier 3

BR 8:
- Condition:
  - If Workgroup = Security & Security Approval = Yes & Change Type = Database
- Action:
  - Set Workgroup = Database

BR 9:
- Condition:
  - If Workgroup = Security & Security Approval = Yes & Change Type = Code
- Action:
  - Set Workgroup = Release Engineering Team

BR 10:
- - Condition:
    - If Workgroup = Security & Security Approval = No
  - Action:
    - Set Workgroup = Tier 3

Difference between Business Rule Designer and Workflow Designer

Business Rule Designer and Workflow Designer are both used for automating certain tasks, however, there are some key differences which highlight the variation in which they can be used:

Business Rule Designer	Workflow Designer
Uses rules for Triggering certain Actions based on Conditions.	Uses a workflow to automate specific processes which would otherwise be done manually.
It is used to define and manage the Business Rules that control how a system works.	It is used to define and automate the steps that are needed to complete a task or process.
Uses a rule engine.	Uses workflow based on if-else conditions.
Actions are manually created when Business rule is created and execute when condition is matched.	Actions are performed by the Service Automation Scripts.
There is no starting point for a Business Rule. User can create a Business rule for any activity such as Resolving an Incident, sending notification etc.	Workflow Design should have a starting point such as Incident, Service request, Work Order.

Best Practices

The following Best Practices will enable your organization to get the most out of Business Rule Designer and produce the best outcomes.

Determine and outline business processes - Outlining the processes will help you identify which ones can be automated, resulting in a more effective system for handling routine procedures.

For example, if you routinely assign questions about one product to a certain queue, you can create a rule to automatically route those incidents to the queue. Or if opportunities aren’t followed up promptly, rules can escalate those opportunities after a certain amount of time.

Review this list of questions to trigger ideas for designing business rules that can increase efficiency in your organization:

How do you handle incoming customer questions?
What is the review process when answers are created?
What happens when incidents are reassigned to other agents?
How does management get involved when incidents remain unresolved?
What happens when sales opportunities are identified?
How are prospective customers contacted?
How do you identify target groups for promotions?
How can you group incoming customer questions and route them most effectively?

Create a rules flowchart - Using flowcharts to view and organise processes can help you choose how to apply business rules. Making a flowchart can assist you with:

Organize business processes.
Gain process consensus between management and staff.
Develop a blueprint for staff training.
Develop thorough testing methods with less backtracking.
Create an overview of the information management process.
Provide a future point of reference.

Create rules—You can write rules to automate business procedures once you have a basic understanding of how rules operate. To find the best strategies for automating routine processes, start by looking at the flowchart of the current processes.

Prioritize processes for applying rules—To make sure that rules function as you intend them to, you must take into account how states, functions, and rules are organised. Up until a rule transition to a function, a different state, or completely stops processing, all the rules in a state are processed sequentially.

Train staff— Your staff needs to be trained after you establish the rule bases. They should be acquainted with how your business conducts routine business operations. Staff members also need to understand how rules automate those processes and how their duties affect rule processing.

Evaluate the processes and rules as required—Once you begin automating processes with rules and gain experience with them, you can think about more effective and efficient ways to route and manage data. Re-examine your business procedures on a regular basis to look for ways to handle inquiries, responses, updates, and opportunities in a more efficient manner. Revaluate your organization's processes whenever they are modified. For instance, when new or existing staff accounts are added, routing rules should be updated.

Prerequisites

Rabbit MQ set up.
To set up Rabbit MQ
1. Download Erlang version 23.0 for the respective operating system and install. Use the default options during the installation and complete the installation. (Link - https://www.erlang.org/downloads/23.0)
2. Set below environment variable under system variables
  Variable name: ERLANG_HOME
  Variable value: Path of erlang without bin
3. Add %ERLANG_HOME%\bin to the PATH environmental variable:
  Variable name: PATH
  Variable value: %ERLANG_HOME%\bin
4. Download and install Rabbit MQ server 3.8.13 (Link - https://github.com/rabbitmq/rabbitmq-server/releases/tag/v3.8.14)
  
  To install Rabbit MQ server 3.8.14, perform the following steps:
  1. Locate and double-click the rabbitmq-server-3.8.14.exe (It will usually be in your Downloads folder.)
  2. A dialog box will appear. Click Yes. The Choose Components screen is displayed.
    
    Figure: Choose Components
  3. Select components to install and click Next. The Choose Install Location screen is displayed.
    
    Figure: Choose Install Location
  4. Select Destination Folder by clicking Browse and and click Install.
    
    Figure: Installing
    
    Figure: Installation Complete
  5. Click Finish to complete the installation.
5. Make sure RabbitMQ is available in services and running.
6. Open the command prompt with admin privileges and navigate to the path where rabbitmq server is installed. Execute the below command to enable the management interface rabbitmq-plugins enable rabbitmq_management
7. Open a browser and access the management interface using the link, http://localhost:15672/
8. Login with credentials guest/guest
Troubleshooting Common Issues:
Erlang home not set correctly
1. On executing rabbitmq-plugins enable rabbitmq_management command if Erlang home not set correctly error is encountered, then restart the server.
2. After server restarts, execute the same command again. The plugins will be installed.

Summit.BusinessRule.EventListenerService service installation

In case of first time upgrade to Tahoe and above versions, the below installation command needs to be executed.

Installation command for Business Rule Service

sc create "Summit.BusinessRule.EventListenerService" binPath= "<<InstallationDirectory>>\BusinessRuleEvent\Summit.BusinessRule.EventListenerService.exe" DisplayName= "Summit BusinessRule EventListener" start= auto sc start Summit.BusinessRule.EventListenerService Example: <<InstallationDirectory>> "E:\ToQA\v511\B013\01.Applications" So the binPath="E:\ToQA\v511\B013\01.Applications\BusinessRuleEvent\Summit.BusinessRule.EventListenerService.exe" sc create "Summit.BusinessRule.EventListenerService" binPath= "E:\ToQA\v511\B013\01.Applications\BusinessRuleEvent\Summit.BusinessRule.EventListenerService.exe" DisplayName= "Summit BusinessRule EventListener" start= auto

New Config keys are required to be added in web.config/app.config file

Config Keys

The below config keys are required to be added to the respective file for Business Rule Functionality.

Web.config of SummitWeb

<add key="BUSINESS_RULE_RABBITMQ_USERNAME" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PASSWORD" value="" /> <!--Comma Separated Hostname or IP Address-->    <add key="BUSINESS_RULE_RABBITMQ_HOST" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PORT" value="5672" /> <!--Connection Timeout value in milli seconds-->    <add key="BUSINESS_RULE_RABBITMQ_CONNECTION_TIMEOUT" value="1000" />

App.config of Summit.BusinessRule.EventListenerService

<add key="BUSINESS_RULE_RABBITMQ_USERNAME" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PASSWORD" value="" /> <!--Comma Separated Hostname or IP Address--> <add key="BUSINESS_RULE_RABBITMQ_HOST" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PORT" value="5672" /> <!--Connection Timeout value in milli seconds--> <add key="BUSINESS_RULE_RABBITMQ_CONNECTION_TIMEOUT" value="3000" /> <add key="BUSINESS_RULE_RABBITMQ_FETCH_COUNT" value="10" /> <add key="DEBUG_ENABLED" value="false" /> <add key="API_TIMEOUT" value="10000" />    <!--Email Processing Config Keys--> <add key="App:BaseURL" value="" /> <add key="Mail:From" value="" /> <add key="Mail:FromName" value="" /> <!--Orchestration Config Keys--> <add key="App:OrchestrationEnabled" value="true" />  <!--Orchestration connector in connection string--> <add name="RabbitConnector" connectionString="" /> <add name="SummitDB" connectionString="" />

ServerMonitor.exe.config

<add key="BUSINESS_RULE_RABBITMQ_USERNAME" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PASSWORD" value="" /> <!--Comma Separated Hostname or IP Address-->  <add key="BUSINESS_RULE_RABBITMQ_HOST" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PORT" value="5672" /> <!--Connection Timeout value in milli seconds-->  <add key="BUSINESS_RULE_RABBITMQ_CONNECTION_TIMEOUT" value="1000" />

Note:

Data Migration across different Database Environment
If the data is migrated between DB environments, make sure that the value for Summit_BusinessRule_Identifier key in Summit_config table must be unique. The same value for Summit_BusinessRule_Identifier configuration key cannot be used across different DB environments.

Note:

If the queue connection is done successfully, it displays the message "Message queue connection check is successful."

If the queue connection is not done successfully, it displays the message "Message queue connection check has failed. Business rules will not be processed."

If the keys are not configured successfully, it displays the message "Message queue connection keys are not configured. Business rules will not be processed."

Loading