Best Practices for Maintaining ServiceNow Configuration Baseline and Documenting Changes

[MGanon]

What are some recommendations for identifying and maintaining a ServiceNow configuration baseline? How do you identify and track what updates (configurations and customizations) have been made to a particular ServiceNow instance? How do compare new functionality requests against that baseline?

Is there something in ServiceNow that can identify what has changed from the OOB baseline? Can ServiceNow generate a new baseline to compare new requests against?

If you track configuration changes with an external document, can you share examples?

[MGanon]

By "ServiceNow configuration baseline", I am referencing actual changes made to ServiceNow like forms, updated or new business rules, scoped applications, etc. I think that the scope of tracking all changes possible to ServiceNow will be far to large to use the CMDB baseline function.

[MGanon]

I found this helpful reference but I am still interested in opinions from others.

View a report on customizations and configuration changes
https://docs.servicenow.com/bundle/tokyo-application-development/page/build/system-update-sets/task/...

[Ratnakar7]

Hi @MGanon ,

Here are some best practices for identifying and maintaining a configuration baseline in ServiceNow:

1. Use Update Sets: ServiceNow provides a feature called Update Sets that allows administrators to group changes into packages that can be easily tracked, reviewed, and applied. Use Update Sets to track all changes made to the instance.

2. Use Source Control: Implement a source control solution to track changes to ServiceNow code, including client-side scripts, business rules, and server-side scripts. By maintaining a source control repository, it's possible to see the history of changes and roll back changes if necessary.

3. Document Changes: It's essential to document all changes made to the platform, including the reason for the change, the date of the change, and the person who made the change. This documentation helps to identify the changes made and the impact on the platform.

4. Review Changes Regularly: Regularly review the changes made to the instance to identify unauthorized or unnecessary changes. Also, review the changes to ensure they align with the organization's security policies and best practices.

5. Test Changes Thoroughly: Before implementing any changes in the production environment, test the changes thoroughly in a non-production environment. This testing ensures that the changes work as expected and do not negatively impact the platform's performance.

6. Create Baseline Reports: Create a baseline report to identify the original state of the platform and compare it against any changes made. This report helps to track changes and ensures that the platform remains consistent.

7. Use Configuration Management: Implement Configuration Management to track and maintain a list of all configuration items, including customizations and configurations, in the ServiceNow instance. This information helps to identify what changes have been made, who made them, and when they were made.

Thanks,

Ratnakar