Skip to content

Conversation

@prashantmrshine
Copy link
Contributor

@prashantmrshine prashantmrshine commented Oct 27, 2025

PR Description:

This code_snippet.js script auto-assign Incident to Last Engineer Who Worked on CI.
This README.md contains what does this scripts do.

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

@Atul-LNG Atul-LNG self-assigned this Oct 27, 2025
Copy link
Contributor

@Atul-LNG Atul-LNG left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @prashantmrshine
A few questions:

Based on my experience, fulfillment work usually happens on the Incident or Change, not directly on the CI. So how can we identify that a CI has been worked upon?

If the last assignee is no longer active or not part of the group, could you please optimize the script a bit more to handle that scenario?

@prashantmrshine
Copy link
Contributor Author

Hi @Atul-LNG

You are getting confused, things are executing in incident only, and optimized the script

@Atul-LNG
Copy link
Contributor

Hi @prashantmrshine Thanks for the clarification. Could you please add an additional validation — for example, if the Incident was last resolved by an engineer a year ago and that engineer is no longer active in the system, then to whom should it be assigned? Using CIs is a good approach, but it’s quite a basic starting point.

Or up to what time period should the Incidents be checked — for example, the last 6 to 9 months? Querying the entire table wouldn’t be an efficient approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants