Business Rules in the Service Request module are server‑side scripts that execute automatically when specified conditions are met. These rules are used to implement system logic such as updating request attributes, enforcing data integrity, initiating notifications, triggering downstream workflows, or invoking integrations. By automating these actions, Business Rules ensure consistent processing of service requests throughout their lifecycle.
The Business Rule Designer provides a centralized interface for creating and managing these rules. Administrators can define execution conditions, configure script logic, and control rule order to ensure predictable system behavior. Using Business Rules, organizations can streamline operational tasks, reduce manual intervention, and maintain standardized handling of service request records.
Key Benefits
User Persona: Administrators
Use Case
Use Case | Solution |
Sam is a Service Desk Coordinator at NovaTech who manages incoming Service Requests across multiple functional teams. Each day, dozens of requests are raised for different catalog items such as VPN Access, Software Installation, and New User Provisioning. One morning, a user submits a “VPN Access Request”, but the Assigned Workgroup field is left blank. This results in delays since the request does not reach the Network Support Team automatically. NovaTech wants to eliminate manual triaging and ensure that catalog-specific requests are always assigned to the correct team at the time of creation. | A Business Rule is configured under Service Request Management using the Business Rule Designer. When a VPN Access request is submitted, the Business Rule evaluates the request and automatically updates the Assigned Workgroup to Network Support Team. |
Configuring Business Rules for Service Request
To configure a business rule, perform the following steps:
Login as Administrator and select Admin Workspace.
Figure: Workspace - Admin
Select Infrastructure from the left panel and then select Business Rule.
Figure: Infrastructure - Business Rule
The Business Rule page is displayed. Select the Department from the left panel.
Figure: Department
Select Add New from the right panel to create a new business rule.
Figure: Business rule – Add New
Fill in the details for the Rule Definition section as shown in the following screen.
Figure: Rule Definition
The below table describes the fields in the Rule Definition of the Business Rule Designer.
Field | Description |
|---|---|
Department | Select one or more Tenants from the drop-down list. |
Business Rule Name | Enter the name to be given to the Business Rule. |
Business Rule Description | Enter a description about what the business rule will accomplish. |
Execution Order | Enter a numeric value representing the order in which the rule should be executed. If there are multiple Business Rules with different order number, then the Business Rule with the highest execution order number would be executed first. |
Active | Enable the Active check box to make the Business Rule active. |
Select Service Request from the Module dropdown.
Figure: Module Selection
When Service Request module is selected, an additional field called Table appears in the configuration.
Figure: Table Selection
Table Field
Field | Description |
Table | Specifies whether the Business Rule applies to all Service Requests or a specific catalog request. |
SR Details | Applies the Business Rule to all Service Requests. |
Catalog Tables | Applies the Business Rule only to Service Requests created from a specific catalog item. |
Note:
The default value for this field is SR Details.
Business Rules for Catalog Tables
When Catalog Tables is selected, administrators can choose a specific catalog request.
In this configuration:
The Business Rule applies only to Service Requests created from the selected catalog.
Both SR Details attributes and catalog-specific attributes are available in the condition builder.
Catalog-specific Business Rules are useful when automation is required only for certain request types.
Execution Order for Catalog Rules
When configuring a Business Rule for a catalog table, the system displays an information icon suggesting that administrators configure a higher execution order if the catalog-specific rule must take priority over SR Details rules.
Execution order determines which rule is executed first when multiple rules apply.
Note:
If both SR Details rules and Catalog-specific rules exist, the rule with the higher execution order will be processed first.
Catalog Rule Limitation
Only one Business Rule can be created for a specific catalog table.
If a rule already exists for the selected catalog:
The system displays a message indicating that a Business Rule is already configured.
A link is provided to open and modify the existing Business Rule instead of creating a new one.
Note:
This limitation ensures that multiple rules do not conflict for the same catalog request.
Choose when to execute the business rule
Figure: Execution Mode Selection
After and Async Business Rule
After Business Rule
Use an After Business Rule in the Service Request module when a Service Request record—or its related data—must be updated immediately after the request is submitted or modified, and the results must be visible to the user right away.
When a Service Request is created or updated, the After rule executes after the data is saved to the database. During this time, the Service Request record is temporarily locked, preventing further updates until the rule completes.
This mode is ideal for actions that must occur before the user continues working, ensuring accuracy and consistency in the Service Request data.
Async Business Rule
The Async Business Rule runs in the background and does not lock the Service Request record. Users can continue working—updating details, adding communication notes, or attaching documents—while the asynchronous logic executes independently.
This mode is best suited for non‑urgent or backend tasks such as:
Updating related tables or linked catalog data
Recalculating downstream values
Triggering integrations
Sending notifications
Performing follow‑up processing on large volumes of requests
Async rules help improve user experience by allowing background operations to run without delaying the user's interaction with the Service Request.
Example Use Cases
Scenario 1 — Auto‑Populate SR Fields Based on Catalog Selection
Context:
Jordan, a Service Desk Analyst, processes incoming requests for hardware provisioning. When users submit requests like Laptop Request or Monitor Request, several internal fields must be filled in before the ticket is routed to the right fulfilment team.
Scenario:
A Business Rule is configured in After execution mode to auto‑populate internal SR fields based on catalog attributes.
If the selected catalog item belongs to the "Hardware Provisioning" category, the rule automatically updates:
Category = Hardware
Assigned Workgroup = End User Computing Team
Priority = Medium
What Happens:
When the Service Request is submitted, the After Rule fires immediately.
The SR record becomes temporarily frozen while Category, Workgroup, and Priority fields are updated.
The values update instantly and become visible to the analyst before further processing.
Why After:
These updates must occur synchronously to ensure the Service Request is routed correctly and consistently before any fulfillment action begins.
Scenario 2 — Enforce Mandatory Data Before Status Change
Context:
Priya, a Service Request Fulfillment Analyst, begins processing a New User Creation request. Before she can move the request to “In Progress”, the system must ensure all mandatory details—such as Manager, Department, and Access Requirements—are filled in.
Scenario:
A Business Rule is configured in After mode to validate mandatory fields whenever the SR status changes to “In Progress”.
The rule automatically:
Checks if mandatory onboarding fields are populated
Updates validation messages
Prevents the status change if required data is missing
What Happens:
When Priya attempts to change the status, the After Rule executes immediately.
The SR record is locked until validations finish.
If mandatory data is missing, the system returns an error and stops the status update.
Why After:
Validations must run after the save but before the user proceeds, ensuring SR data is complete and accurate for subsequent workflow steps.
Example Use Cases for Async Execution Mode
Scenario 1 — Notify Approvers for High‑Priority Requests
Context:
NovaTech treats certain Service Requests—such as Privileged Access Requests—as high priority due to security risks. When such a request is submitted as Priority 1, several stakeholders must be notified.
Scenario:
An Async Business Rule is configured to send notifications to:
Security Operations
Access Governance Team
SR Approver
Requestor’s Manager
whenever a Service Request is updated to Priority 1.
What Happens:
The SR record remains unlocked and editable.
Notifications are processed in the background.
Analysts can continue their work without waiting for the notification process.
Why Async:
Notifications do not affect the workflow immediately and can run quietly in the background without interrupting user activity.
Scenario 2 — Auto‑Update Related Catalog Data in Background
Context:
Ethan, an SR Analyst, receives a Software Installation Request for multiple applications. Once the SR is submitted, the system must update several related catalog entries and dependency tables in the backend.
Scenario:
An Async Business Rule is configured to:
Update linked catalog request tables
Check for license availability
Log backend updates in the SR audit trail
Notify the Fulfillment Team if licenses are insufficient
This rule runs whenever the SR is created or modified.
What Happens:
The rule runs asynchronously while Ethan continues updating comments or attaching documents.
The system processes catalog updates in the background without freezing the SR.
Large or complex backend operations do not delay the user.
Why Async:
Updating multiple related records and performing license checks may take time. Running these tasks asynchronously prevents user interruption and improves system responsiveness.
Select the Trigger Type from the options.
Figure: Trigger Selection
Trigger Types
The following trigger types are supported for Service Request Management:
Create: Select this checkbox to execute the Business Rule when a Service Request record is created.
Update: Select this checkbox to execute the Business Rule when a Service Request record is updated.
Schedule: Select this checkbox to execute the Business Rule at scheduled intervals.
Note:
If the Schedule checkbox is selected, the When field must be set to Async.
A calendar icon is displayed when a scheduled job is configured for the Business Rule.
The available trigger types depend on the selected table.
SR Details
The following trigger types are supported:
Create
Update
Schedule
Catalog Tables
The supported triggers are:
Create
Schedule
Note:
Update triggers are not supported for catalog tables.
Scheduled Business Rules
Business Rules configured with the Schedule trigger are executed automatically at defined intervals. These rules are useful for automating time‑based actions within the Service Request lifecycle.
Execution Time Options:
Administrators can choose when the scheduled rule should run:
Anytime
Only during business hours
Only outside business hours
Note:
Scheduled Business Rules are helpful for automating periodic Service Request maintenance activities, such as aging checks, reminders, and auto‑closure of inactive requests.
Choose the conditions based on which the rule executes.
Figure: Condition
Conditions
A condition is made up of a field, an operator, and a value. You can create complex conditions for Business Rules by combining multiple conditions using logical operators such as AND or OR.
You can use the Condition Builder to define when Business Rule actions should be executed. When a service request arrives, the user can select one of the following options:
Conditions based on criteria: Select this radio button to define specific conditions under which the action should be executed.
No Condition: Select this radio button if the action should always be executed, regardless of request attributes.
Grouping of Conditions
When multiple conditions need to be evaluated together, they can be grouped within a Business Rule. This is achieved by combining AND / OR operators along with the grouping functionality provided in the tool. Grouping ensures conditions are processed logically and accurately.
Example Scenario
Scenario
Fredrick wants to automatically close low-impact Service Requests that belong to the End User Computing workgroup once they are fulfilled, ensuring completed and low-priority requests do not remain unnecessarily open in the system.
Solution
Trigger
Module: Service Request Management
Trigger Type: Schedule
Condition
Status = Fulfilled
AND Priority = Low
AND Impact = Low
OR (Assignment Group = End User Computing AND Impact = Medium)
(Grouped condition ensures that requests from the End User Computing group with higher impact are evaluated correctly.)
Action
Update field: Status = Closed
Figure: Example of grouped conditions
List of Supported Fields:
Field Name | Field Key | Type | Attribute Type | Notification and API Key |
Requestor | CALLER | user_search | User Attributes | *CALLER* |
Logged By | LOGGED_BY | user_search | User Attributes | *LOGGED_BY* |
User Type | USER_TYPE | dropdown | User Attributes | *USER_TYPE* |
Customer | CUSTOMER | user_search | User Attributes | *CUSTOMER* |
Location | LOCATION | user_search | User Attributes | *LOCATION* |
Caller Location | CALLER_LOCATION | user_search | User Attributes | *CALLER_LOCATION* |
SR ID | SR_ID | number | Standard Attributes | *SR_ID* |
Workgroup / Assigned Workgroup | WORKGROUP | dropdown | Standard Attributes | *WORKGROUP* |
Analyst/Assigned To | ASSIGNED_TO | dropdown | Standard Attributes | *ASSIGNED_TO* |
Status | STATUS | dropdown | Standard Attributes | *STATUS* |
Classification | CLASSIFICATION | treeview | Standard Attributes | *CLASSIFICATION* |
Impact | IMPACT | dropdown | Standard Attributes | *IMPACT* |
Urgency | URGENCY | dropdown | Standard Attributes | *URGENCY* |
Priority | PRIORITY | dropdown | Standard Attributes | *PRIORITY* |
SLA Service Window | SLA_SERVICE_WINDOW | dropdown | Standard Attributes | *SLA_SERVICE_WINDOW* |
Pending Reason | PENDING_REASON | dropdown | Standard Attributes | *PENDING_REASON* |
Closure Code | CLOSURE_CODE | dropdown | Standard Attributes | *CLOSURE_CODE* |
Resolution Code | RESOLUTION_CODE | dropdown | Standard Attributes | *RESOLUTION_CODE* |
Source | SOURCE | dropdown | Standard Attributes | *SOURCE* |
Aging (In Hours) | AGING | number | Standard Attributes | *AGING* |
Medium | MEDIUM | dropdown | Standard Attributes | *MEDIUM* |
Scheduled Requests | SCHEDULED_REQUESTS | checkbox | Standard Attributes | *SCHEDULED_REQUESTS* |
Has Attachment | HAS_ATTACHMENT | checkbox | Standard Attributes | *HAS_ATTACHMENT* |
Response SLA Violation | RESPONSE_SLA_VIOLATION | checkbox | Standard Attributes | *RESPONSE_SLA_VIOLATION* |
Resolution SLA Violation | RESOLUTION_SLA_VIOLATION | checkbox | Standard Attributes | *RESOLUTION_SLA_VIOLATION* |
Has Workorders | HAS_WORKORDERS | checkbox | Standard Attributes | *HAS_WORKORDERS* |
Child Service Requests | CHILD_SERVICE_REQUESTS | checkbox | Standard Attributes | *CHILD_SERVICE_REQUESTS* |
View All Service Requests | VIEW_ALL_SERVICE_REQUESTS | checkbox | Standard Attributes | *VIEW_ALL_SERVICE_REQUESTS* |
Response SLA | RESPONSE_SLA | singleselection | Standard Attributes | *RESPONSE_SLA* |
Resolution SLA | RESOLUTION_SLA | singleselection | Standard Attributes | *RESOLUTION_SLA* |
Show Requests Updated By Email | SHOW_SERVICE_REQUESTS | checkbox | Standard Attributes | *SHOW_SERVICE_REQUESTS* |
Description | DESCRIPTION | textarea | Standard Attributes | *DESCRIPTION* |
Solution | SOLUTION | textarea | Standard Attributes | *SOLUTION* |
Subject | SUBJECT | textarea | Standard Attributes | *SUBJECT* |
Extended SR | EXTENDED_SR | checkbox | Standard Attributes | *EXTENDED_SR* |
Is Recording Available | ISRECORDINGAVAILABLE | checkbox | Standard Attributes | *ISRECORDINGAVAILABLE* |
Remaining SLA Time | REMAINING_SLA_TIME | number | Standard Attributes | *REMAINING_SLA_TIME* |
Log Time | LOG_TIME | date | Date | *LOG_TIME* |
Updated Date | UPDATED_DATE | date | Date | *UPDATED_DATE* |
Updated Since (In Days) | UPDATED_SINCE | number | Date | *UPDATED_SINCE* |
Pending For (In Days) | PENDING_FOR | number | Date | *PENDING_FOR* |
Actual Efforts | ACTUAL_EFFORTS | number | Date | *ACTUAL_EFFORTS* |
Final Approval Time | FINAL_APPROVAL_TIME | date | Date | *FINAL_APPROVAL_TIME* |
Closure Category | CLOSURE_CATEGORY | treeview | Standard Attributes | *CLOSURE_CATEGORY* |
Response SLA Violation Reason | RESPONSE_SLA_REASON | text | Standard Attributes | *RESPONSE_SLA_REASON* |
Resolution SLA Violation Reason | RESOLUTION_SLA_REASON | text | Standard Attributes | *RESOLUTION_SLA_REASON* |
Cancellation Remarks | CANCELLATION_REMARKS | textarea | Standard Attributes | *CANCELLATION_REMARKS* |
Service Category | SERVICE_CATEGORY | treeview | Standard Attributes |
Actions
An Action is performed automatically once the condition is met. You can define a Business Rule with only action and no condition or with both. Business Rule Actions are a configurable way to:
Update Fields
Notification
API
Update Fields
The Update Fields section allows you to update any of the supported fields. Once you select the Field from the Dropdown, the Value field will appear based on the field selected.
To Update a Field, perform the following steps:
1. Select the Update Fields option.
Figure: Update Fields
2. Under Update Action Type, select the update action mode.
Figure: Update Action Type
Note:
Update values first time: If selected, the field will be updated only first time when the condition and trigger is met.
Update values every time: If selected, the field will be updated every time the condition and trigger is met.
3. Click Add icon to add a condition field and select the Field value from the dropdown.
Figure: Update Action Type
4. Once you select the Field, the Value field will appear as shown. 
Figure: Value Field
Once done, click Submit.
Figure: Submit
Mandatory fields based on Status
Status | Mandatory field key |
|---|---|
New | URGENCY, IMPACT, PRIORITY, WORKGROUP, SLA_SERVICE_WINDOW |
Assigned | URGENCY, IMPACT, PRIORITY, ASSIGNED_TO |
In-Progress | URGENCY, IMPACT, PRIORITY, CLASSIFICATION, WORKGROUP, ASSIGNED_TO, SLA_SERVICE_WINDOW, ACTUAL_EFFORTS |
Pending | URGENCY, IMPACT, PRIORITY, CLASSIFICATION, WORKGROUP, ASSIGNED_TO, SLA_SERVICE_WINDOW, PENDING_REASON, ACTUAL_EFFORTS |
Resolved | URGENCY, IMPACT, PRIORITY, CLASSIFICATION, WORKGROUP, ASSIGNED_TO, SLA_SERVICE_WINDOW, RESPONSE_SLA_REASON, RESOLUTION_SLA_REASON, RESOLUTION_CODE, CLOSURE_CODE, CLOSURE_CATEGORY, SOLUTION, ACTUAL_EFFORTS |
Closed | WORKGROUP, URGENCY, IMPACT, PRIORITY, CLASSIFICATION, ASSIGNED_TO, CLOSURE_CODE, CLOSURE_CATEGORY, ACTUAL_EFFORTS |
Cancelled | CANCELLATION_REMARKS |
In the Update Field action, when the request status is transitioned to the below stage, all associated mandatory fields must also be populated or updated accordingly.
Status | Mandatory Fields |
New | Urgency |
Impact P | |
Priority | |
Workgorup | |
Service Window | |
Target Completion | |
Location | |
Profile | |
Project | |
Available Resource | |
Assigned |
|
In-Progress | Assigned To |
Response SLA Violation Reason | |
Actual Efforts | |
Pending | Pending Reason |
Actual Efforts | |
Resolved | Solution |
Resolution Code | |
Closure Category | |
Resolution SLA Violation Reason | |
Checklist | |
Actual Efforts |
Status-Based Update Behavior
When updating the Status field, only valid status transitions are allowed.
Supported Status Transitions
Current Status | Allowed Transitions |
New | New, Cancelled |
Initial Authorization | Initial Authorization, Root Cause Analysis Submitted, In-Progress, Pending |
Root Cause Analysis Submitted | Root Cause Analysis Submitted, Reviewed |
Pending | Pending, In-Progress, Reviewed, Testing, Resolved |
Reviewed | Reviewed, Pending, In-Progress, Testing, Resolved |
In-Progress | In-Progress, Pending, Reviewed, Testing, Resolved |
Testing | Testing, In-Progress, Reviewed, Pending, Resolved |
Resolved | Resolved, Closed |
Notifications
Under this tab, you can configure the notifications for the business rule. Business Rules can send notifications to recipients when defined conditions are met.
E- Mail Notification
Email notifications are a way to keep the recipients updated on the progress of your projects through emails.
To create an Email Notification, perform the following steps:
Select Notifications and click Add Notification.
Figure: Add Notifications
Enter the Notification Name and select the notification medium i.e., Email or SMS.
Figure: Notification Name and Medium
Under the Recipient section, select the recipients.
Figure: Recipient Selection
Type in the Email Subject and body as required.
Figure: Email Subject and body
Note:
Use Dollar ('$') and type a character to trigger suggestions for Problem Attributes.
Recipients
Understanding and using the recipient section appropriately helps in effectively notifying the stakeholders. The recipient is divided mainly into two sections which are displayed based on the selected medium:
To - The "To" field is used to specify the primary recipients of the notification. These are the individuals or groups that the sender expects to read and respond. Include the main recipients who are directly involved or expected to take action.
Cc - The "CC" field is used to include additional recipients who may be interested in the notification content. CC recipients are not the main addressees but are still receiving a copy for information. Inform others or keep them in the loop without making them the primary audience.
You can add the type of recipient based on their groups. The types of recipients are explained in the following table:
Group | Members | Description |
By Caller Group |
|
|
By Analyst Group |
|
|
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 Custom Email ID | Type in required e-mail id. | You can add the email id of the recipient manually using this option. |
By Custom Attribute | Search and select the required Attribute. | By selecting this option, you can search a recipient by the required custom attribute. |
By Approver Group | Search and select the required Approver Group. | By selecting this option, you can search a recipient by the required Approver Group. |
SMS Notification
To create an SMS notification, perform the following steps:
Under the Notification tab, click Add Notification. The Notification pop-up is displayed.
Figure: Add Notifications
Select Medium as SMS to create SMS notification.
Figure: Medium – SMS
Fill in the required details. For more information, see Field Description.
Figure: SMS Configuration
Note:
Use Dollar ('$') and type a character to trigger suggestions for Problem Attributes in Description.
Click Save. A new SMS Notification is created and displayed under the Unlinked Notifications section.
Figure: Unlinked Notification
Note:
Click (Edit) icon to edit the template details as shown above. Click (Delete) icon to delete a template.
Field Description
The following table describes the fields on the Notification pop-up:
Field | Description | ||||||||||||||||
Notification Name | Type in the name for the SMS notification template. | ||||||||||||||||
Medium | Select the medium as SMS to configure SMS notification. | ||||||||||||||||
To | Add the main recipients of the email.
| ||||||||||||||||
Message Expiry Time (Mins.) | Specify the message expiry time in minutes | ||||||||||||||||
Description | Type in the detailed description. |
API Action
API stands for application programming interface. It is a set of protocols and tools that allow the Apex Platform to interact with other third-party applications. This can include anything from retrieving or transferring data to third-party applications, managing or controlling software.
To add API, perform the following steps:
Under the API tab, click Add API. The API pop-up is displayed.
Figure: API
Fill in the required details. For more information, see Field Description.
Figure: API Configuration
Click SAVE. A new API is created and displayed under the Unlinked Notifications section.
Field Description
The following table describes the fields on the API pop-up:
Field | Description |
API Configuration Name | Type in the Name for the API Configuration. |
Method | Select the required Method from the drop-down list. The available methods are:
|
API Timeout (In seconds) | Specify the Timeout in seconds |
API URL | Specify the API URL |
Params | You can send path and query parameters with your requests using the Params tab. To send a path and query parameter,
|
Authentication | Authentication involves verifying the identity of the client sending a request, and authorization involves verifying that the client has permission to carry out the endpoint operation. Open the Authorization tab to configure your access details. Select the required Authentication type from the drop-down list. The available types are:
|
Headers | Some APIs require you to send particular headers along with requests, typically to provide additional metadata about the operation you are performing. You can set these up in the Headers tab. Enter any key-value pairs you need and will send them along with your request. |
Body | The Body tab allows you to specify the data you need to send with a request. |
Response | Under this tab, you can view the API response. |
Linked to this Business Rule
Under this section, you can view the list of APIs linked to this Business Rule. Also, you can edit and delete the APIs available under this section.
Linked to other Business Rule
Under this section, you can view the list of APIs linked to other Business Rules. Also, you can edit and delete the APIs available under this section.
Unlinked APIs
Under this section, you can view the list of unlinked notifications. These notifications are created but not linked with any business rule.
Interaction with Catalog Default Values
Within the Catalog Additional Information configuration, administrators may define default or conditional values for Service Request fields.
If a Business Rule updates the same field:
The Business Rule update takes precedence over the catalog configuration.
The value defined in the Business Rule will overwrite the existing configuration.
Note:
Business Rule updates override both default values and conditional configurations defined in the catalog.
Impacted Scenarios
Business Rules configured for the Service Request module also apply to Service Requests created through other system actions.
For example:
Convert to Request
When an Incident is converted into a Service Request using the Convert to Request option, the configured Business Rules are triggered based on the defined conditions and triggers.