--- title: "Business Rule Designer" slug: "business-rule" updated: 2026-03-03T06:35:51Z published: 2026-03-03T06:35:51Z canonical: "help.symphonysummitai.com/business-rule" --- > ## Documentation Index > Fetch the complete documentation index at: https://help.symphonysummitai.com/llms.txt > Use this file to discover all available pages before exploring further. # Business Rule Designer ## 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. ###### ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Overview(7).png) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/BR benefits.png) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/BRD1(2).png) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/BRD_update_presentation_grade_6x.png) 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?** **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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-r7nzicst.png)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**.** **![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-tf3l13xb.png)** 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-scq978ne.png) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-787n5csc.png) 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. | #### **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. It is recommended to perform 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 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Condition.jpg) 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}} ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Condition1.jpg) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-1otlack8.png) {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: ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-glrgugfl.png) 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 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Data string.jpg) 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: ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Date.jpg) Figure: Date Example ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-43zmau4z.png) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Date 2.jpg) 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: ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Numeric value.jpg) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-ik5nyhe6.png) 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 warranty start date, then the operators loaded are as shown below: ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Proce.jpg) Figure: Price Example You can select other an operator such as **Between** to select the warranty start date between two different dates. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Cost between.jpg) Figure: Between operator Example. Similarly, the different operators that can be used are as shown below: ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-ennh66u9.png) 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: 1. Date 2. Dropdown 3. Numeric 4. 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-xx1u96tj.png) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-ud7uyje3.png) 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: ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-7n3jqmd5.png) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-saci7zca.png) Figure: String Value Example #### 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: ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Actions.jpg) 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] > Note: > > Based on the module selected by the user, the relevant standard fields belonging to that module will appear in the Update Fields section. #### **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**** | **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**** | S.No. | Use Case User 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] > 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 #### **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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Notification email.jpg) Figure: Email Template Notification #### **SMS Notification** You can also create SMS Notifications by selecting the **SMS** option under **Medium.** #### **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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/API.jpg) Figure: Illustration of action to configure a new API ## 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 ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/bru1.jpg) Figure: Example of Trigger configuration **Condition:** - CSAT Rating = 1 ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/bru2.jpg) Figure: Example of Condition **Action:** - To send a **SAD CSAT Notification** Email to **Analyst** and Incident **Workgroup Owner** ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/bru3.jpg) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-nlpumqy7.png) 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. **![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-z989trff.png)** 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 ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/bru4.jpg) 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: ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/bru5.jpg) 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. *![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-i07960mn.png)* 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 ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Condition3.jpg) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Email.jpg) 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: ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-n6bjcd4g.png) Figure: Example of action to update the fields ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-qbmjs71l.png) 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. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Trigger(1).jpg) Figure: Trigger Type as Create/Update b. Define the condition as **Impact** and **Urgency** as shown below: ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Condition4.jpg) 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 ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Condition5.jpg) Figure: Condition Example **Action:** To send the auto resolve notification to caller after 2 days. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Notification2.jpg) 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 = Yes**Action:** - 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 1. 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](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 ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-n8npahnn.png) ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-gxgrpd34.png) 1. Add %ERLANG_HOME%\bin to the PATH environmental variable: Variable name: PATH Variable value: %ERLANG_HOME%\bin ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-itep73cy.png) ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-1uexanu6.png) 1. Download and install Rabbit MQ server 3.8.13 (Link - [h](https://github.com/rabbitmq/rabbitmq-server/releases/tag/v3.8.14)[ttps://github.com/rabbitmq/rabbitmq-server/releases/tag/v3.8.14)](https://github.com/rabbitmq/rabbitmq-server/releases/tag/v3.8.14)) To install Rabbit MQ server 3.8.14, perform the following steps: a. Locate and double-click the rabbitmq-server-3.8.14**.exe** (It will usually be in your Downloads folder.) b. A dialog box will appear. Click **Yes**. The **Choose Components** screen is displayed. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-3hml4e4p.png) Figure: Choose Components c. Select components to install and click **Next**. The **Choose Install Location** screen is displayed. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-48smkh4s.png) Figure: Choose Install Location d. Select Destination Folder by clicking Browse and and click **Install**. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-537hvw3b.png) Figure: Installing ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-j22nnt3m.png) Figure: Installation Complete ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/business-rule-image-znkv47ub.png) e. Click **Finish** to complete the installation. 2. Make sure RabbitMQ is available in services and running. 3. 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 4. Open a browser and access the management interface using the link, [http://localhost:15672/](http://localhost:15672/) 5. 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. 1. 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** ```plaintext sc create "Summit.BusinessRule.EventListenerService" binPath= "<>\BusinessRuleEvent\Summit.BusinessRule.EventListenerService.exe" DisplayName= "Summit BusinessRule EventListener" start= auto sc start Summit.BusinessRule.EventListenerService Example: <> "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   ``` 1. 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** ```plaintext         ``` **App.config of Summit.BusinessRule.EventListenerService** ```plaintext       ``` **ServerMonitor.exe.config** ```plaintext     ``` > [!NOTE] > 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] > 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."