Business Rule Scenarios

Set up → Automation → Business Rules

Business rules can automate IT tasks and are site-specific.

1. Each site requires a separate Business Rule (BR) due to its site-specific nature. Therefore, site criteria will not be found under the condition.

2.Turn on cascade execution → if you want successive business rules to be applied on the request. By default, business rules stop executing after one business rule is applied on a request.

3. Turn Off cascade execution → Disabling this option ensures that once the current business rule is applied to a request, no further business rules will be executed.

4. Enable the Override request values with Business Rule values option under Field Update if you want the business rule to take precedence over the values in the incoming request.

Scenario 1 :-Field update

The client wants to automate the assignment of field values for incoming requests, triggered by specific keywords (internet down) found within emails or portal submissions.

Scenario 2 :- Field update

The client wants to switch to a specific template and set the priority to High for requests from a certain domain.

Scenario 3 :- (Abort process execution)

Clients can utilize this functionality to restrict certain operations based on specific criteria.

For instance, they can prevent placing a request On-hold if a designated field value is empty.

Clients can also use this feature to prevent the creation of requests outside of operational hours or on holidays, as demonstrated below.

Scenario 4 :- Business Rule based on Sub-Entity (Tasks)

The customer wants to include the "Perform Audit on Server Level" task in a predefined request template, with designated owners at each site responsible for audits based on the Server Category. A custom Server Category field (e.g., Database Server, Web Server, Application Server) has been added to the task template for classification.

To streamline the process and eliminate manual assignment, the customer seeks to automate task assignment by dynamically assigning the designated owner based on the selected Server Category. This ensures the right team or individual handles the audit, improving efficiency and accountability across multiple sites.

Steps to Achieve the Above Scenario  

1. Navigate to Setup → Templates & Forms → Task Template & Layout → Task Layout and click on New Task Layout if the custom fields added to this task are specific and not applicable to the default layout.

Note: Editing the default layout will be applicable to all existing tasks using the default layout.

2. Add a new layout called Server Audit Layout and include new fields using the Drag & Drop section available on the right side of the screen, as shown below.

  3. Now, add a new task template named "Perform Audit on Server Level" and select the required modules. Click on the dropdown next to the default layout and select Server Audit Layout, which was created in the previous step.       

  

4. Follow the procedure to associate the task template with the request by navigating to Templates & Forms → Incident Template → Select the required template → Tasks → Click Add Task from Template.

Points to Remember → If required, you can associate request fields to the task view by clicking on "Associate Request Fields". This allows you to view the request fields while working on tasks from the task details page. 

Business Rule Creation Based on Sub-Entity (Tasks)  

1. Navigate to Setup → Automation → Business Rule → Incident Business Rule.

2. Select the required site by clicking on "Filter by Site".

3. Create a new Business Rule named "Server Audit - Owner Assignment".

4. Set Rule Applies To as "Tasks".

5. Configure execution conditions:

• Execute when a task is created and edited.

• Execute anytime and enable cascade execution.

6. Define the conditions:

• Title contains: "Perform Audit on Server Level".

• Additional Fields/Server Category is: "Database Server, Web Server".

• Check "When any field in the condition is edited".

7. Configure Execute Custom Actions:

• Select Field Update → Owner and assign the appropriate technician.

• Enable "Override task values with Business Rule values" under Field Update if you want the Business Rule to take precedence over the values in the created task.

8. Repeat the Business Rule creation for each site, as Business Rules are site-specific.

Scenario 5:- Business Rule for Field Update (Change):-

A company follows a structured change management process where every change request must pass through a CAB Approval stage before implementation. However, once a change is approved, there is often a delay in updating the Scheduled Start Time, leading to inconsistencies in the change schedule.

​

To streamline the process, a business rule is required to automatically update the Scheduled Start Time to the current time as soon as the change is approved in the CAB stage.

​

1. Business Rule for change is not site based, if required site can be included as a condition.

2. Turn on cascade execution → if you want successive business rules to be applied on the change. By default, business rules stop executing after one business rule is applied on a change.

3. Turn Off cascade execution → Disabling this option ensures that once the current business rule is applied to a change, no further business rules will be executed.

4. Enable the Override request values with Business Rule values option under Field Update if you want the business rule to take precedence over the values in the incoming request.

​

Steps to achieve the above scenario :-

• Create a New Business Rule and name it "Set Scheduled Start Based on CAB".

• Select "Rule Applies To" as Change.

• Set Execution Criteria:

• Execute when a change is Edited.
• Set execution timing to "Anytime".

• Turn on Cascade Execution if required.

• Set the Condition:

• Status is "Approved >> CAB Evaluation".
• Enable "When any field in the condition is edited".

• Add Action:

• Set Scheduled Start Time to Current Time.

• Save and Enable the Rule.

 

 

Scenario 6 :- Abort operation Sample for Change Module.

Once a change request reaches the Closed status, no further modifications should be allowed to critical fields like Description or other key attributes. This prevents unauthorized alterations and maintains the integrity of change records.Hence creating a below BR to abort the operation performed by any user on a closed change.

Steps to achieve the above scenario :-

• Create a New Business Rule and name it "Set Scheduled Start Based on CAB".

• Select "Rule Applies To" as Change.

• Set Execution Criteria:

• Execute when a change is Edited.

• Set execution timing to "Anytime".

• Turn on Cascade Execution if required.

• Set the Condition:

• Status is "Approved >> CAB Evaluation".

• Enable "When any field in the condition is edited".

• Add Action with a custom message as included in the screenshot.

 

Note :- The Parent/Child condition in a business rule ensures that both parent and child criteria are checked together. This allows multiple sets of Parent/Child conditions within the same rule.

To create a Parent/Child condition, click the dots next to the condition and drag them to the right to nest them accordingly.

All the above scenarios are sample cases and can be customized based on your specific requirements. If you need further assistance, feel free to reach out to support for additional queries.

If you do not intend to perform any user-specific operations on a closed change and only want to apply a basic operation such as copying changes or adding notes for all users, you can navigate to Setup → Advanced Portal Settings → Change Management Settings and save the changes.