Iamshankha/Smart Incident Assignment – Auto-Assign Incident to Idle Members

[iamshankha]

PR Description:

🛠️ Smart Incident Assignment – Auto-Assign Incident to Idle Members

📘 Overview

This Business Rule automatically assigns incidents to a predefined support group when specific keywords, such as “disaster” or “emergency”, are present in the incident’s short description. It also ensures that incidents are distributed among group members who are currently idle, maintaining workload balance across the team.

🧩 Problem Statement

During critical situations, incidents tagged as disaster or emergency need immediate attention.
Manually assigning these incidents can lead to:

Delays in response

Uneven workload distribution among support team members

Errors in group assignment

💡 Solution

The Auto-Assign Support Group Business Rule solves this by:

Checking if the incident’s short description contains “disaster” or “emergency”.

Automatically populating the Assignment Group field with Support Group.

Scanning all active members of the group and checking if they already have open incidents.

Assigning the incident to the first idle member to ensure balanced workload.

Providing an info message if all members are currently busy, allowing fallback handling.

🚀 Benefits

✅ Ensures critical incidents are promptly assigned to the correct support team.

✅ Maintains balanced workload across team members, avoiding overloading a single user.

✅ Eliminates manual assignment errors, saving time and improving response efficiency.

✅ Enhances operational visibility and accountability in high-priority scenarios.

🛠️ Implementation

Table: Incident [incident]

Business Rule Type: Before Insert / Before Update

Trigger: When short description contains disaster or emergency

Pull Request Checklist

Overview

• Put an x inside of the square brackets to check each item.
• I have read and understood the CONTRIBUTING.md guidelines
• My pull request has a descriptive title that accurately reflects the changes and the description has been filled in above.
• I've included only files relevant to the changes described in the PR title and description
• I've created a new branch in my forked repository for this contribution

Code Quality

• My code is relevant to ServiceNow developers
• My code snippets expand meaningfully on official ServiceNow documentation (if applicable)
• I've disclosed use of ES2021 features (if applicable)
• I've tested my code snippets in a ServiceNow environment (where possible)

Repository Structure Compliance

• I've placed my code snippet(s) in one of the required top-level categories:
  • Core ServiceNow APIs/
  • Server-Side Components/
  • Client-Side Components/
  • Modern Development/
  • Integration/
  • Specialized Areas/
• I've used appropriate sub-categories within the top-level categories
• Each code snippet has its own folder with a descriptive name

Documentation

• I've included a README.md file for each code snippet
• The README.md includes:
  • Description of the code snippet functionality
  • Usage instructions or examples
  • Any prerequisites or dependencies
  • (Optional) Screenshots or diagrams if helpful

Restrictions

• My PR does not include XML exports of ServiceNow records
• My PR does not contain sensitive information (passwords, API keys, tokens)
• My PR does not include changes that fall outside the described scope

[snamjosh]

Thank you for your contribution.
However, this feature is available OOB with major incident management where you can configure trigger rules for major incidents.

https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/incident-management/task/major-incident-trigger-rules.html

Also, triggering business rules just based on short description isn't a good practice since it will lead to downstream process issues. Major incident should be triggered based on trigger rules.

I will be closing this PR now.