Feature/Preserving System Fields During Updates

[SumithThota]

PR Description:

This background script pattern demonstrates how to update user editable fields on a record while preserving system managed fields (such as sys_created_by, sys_created_on, sys_updated_by, sys_updated_on, and sys_mod_count) and avoiding unintended side effects.

Overview

When programmatically updating records you may want to:

• Update a subset of fields (business fields) while leaving system fields untouched.
• Preserve created/updated metadata when performing a migration or bulk update in a safe way.

This snippet shows a conservative approach: copy only allowed fields from a source object, avoid writing system fields, and use GlideRecord's update operations safely.

Proposed Script

1. Initializes a GlideRecord object for a specified table.
2. Applies a query condition to filter which records should be updated.
3. Iterates through matching records using a while (gr.next()) loop.
4. Temporarily disables:
   • System field updates (sys_updated_by, sys_updated_on)
   • Business rules, flows, and workflows
5. Sets new field values using setValue() for both normal and reference fields.
6. Saves the updated records with update().

Screenshot

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

[ravichandra1998g]

we appreciate the effort you’ve put into this contribution. We’ve labeled it as hacktoberfest-accepted so it still counts toward your Hacktoberfest progress. Thank you for contributing!

This will not be merged as these are well known standard methods to stop system filed updates and there are many - examples of this use case in ServiceNow Community.

For Hacktoberfest, we’re aiming for high-quality contributions providing real-world use developer cases.
You can see some of the recently merged PRs to know the kind of code snippets we are aiming for.

Please reopen/ submit a new one after adding more dynamic context/use cases that are more suitable for the open source

Expanded Snippets: Code snippets reused from the ServiceNow Documentation or API References are acceptable only if they are expanded in a meaningful way (e.g., with additional context, documentation, or variations).

[SumithThota]

Hi @ravichandra1998g,
Thank you for reviewing my PR and for mentioning that it’s labeled as hacktoberfest-accepted, but
I just noticed the label hasn’t been added yet on this PR. Could you please add it when you get a chance?
Really appreciate your time and feedback!