Attachments check for High Risk/Impact change request before moving to Scheduled/Implement Phase

[Soumyadeep10]

PR Description:

This Before Update business rule acts as a safeguard in a Change management process, ensuring that critical changes(those marked as high impact or high risk) are properly documented before progressing to key implementation stages.

What It Does: -The BR triggers before a change request record is updated, specifically when the state changes to either Scheduled or Implement.

-It checks whether the change is classified as high impact or high risk.

-If the change meets either of those criteria, it verifies that at least two attachments are present on the record. These attachments are expected to be essential supporting documents like an Implementation Plan or Backout Procedure.

-If the required documentation is missing, the rule blocks the state change and displays an error message to the user, preventing the change from moving forward until compliance is met.

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

[mskoddow]

Thank you for your contribution. However, there are two issues that need to be fixed before I can approve it:

• The readme does not contain any information on how to configure the Business Rule (table, type, condition, etc)
• Usage of "getRowCount()" is not recommended and bad praxis. In the Hacktoberfest repositories we want to demonstrate how it's done the right way. Therefore, please provide a version with the usage of COUNT in a GlideAggregate. See https://developer.servicenow.com/blog.do?p=/post/training-glideagg/ for more information.

Many thanks!

[Soumyadeep10]

Hello @mskoddow ,
I have updated both the files with the changes you have asked for. Please do review.
Thank you.

[mskoddow]

Looks good! Many thanks for the modifications!

[Soumyadeep10]

Thank you @mskoddow !