Best Practices for Using ServiceNow Team Development

If you’re an active ServiceNow user, you likely have many different instances with a couple of developers on your team. This can cause problems if multiple developers are working on the same instance. Because of this, ServiceNow developed the ServiceNow Team Development Module to enable a conflict-free and transparent development process.

This module enables developers to work on different ServiceNow instances and share code without contradictions. In a single dashboard, team development activities can be monitored. The module tracks changes to various record versions between instances. You can compare different development instances, locates disparities, and fix gaps. Here we explain the capabilities of ServiceNow Team Development.

What are the ServiceNow Team Development Capabilities?

Instance Hierarchies

Within instance hierarchies, each sub production instance acts as a parent instance. Every parent instance is a peer instance and the distributed version control systems between instances and each instance are a source repository or branch.

Pulls and Pushes

Using these methods, developers can synch all instances to the parent instance of a record. Developers must resolve code collisions before updating various versions to the parent instance using the pushing method. The pulling operation extracts modified versions of a record from the parent instances. It is to be remembered that, when pushing is performed on a parent instance the most recent version will be updated. These operations list in the dashboard shows which user made the changes.

Versions and Local Changes

Version logs all changes in a customizable record. Whenever the developer makes changes to the customizable record version, a record is created. Whereas the local change record created, references to the record that the developer is working currently.

Code Review Workflow

• The workflow starts when updates are pushed to the parent instance
• Check if code review property is in an active state in the parent instance
• Set stage to Awaiting Code Review and needs approval before moving to the next step
• Upon approving the code review, a notification is triggered for the code review group to assess the changes
• Load the approved changed or reject them by setting the stage as Code Changes Rejected

Notifications

Email notifications request code reviews of an instance from the developer. The notification workflow sends notifications to all members of the Team Development Code Reviewers group.

To set up email notifications, set the property below:

System Properties > Email Properties: Enable the: Email sending enabled checkbox must be true

ServiceNow Team Development Process

When the change is reconciled and moved back down the chain, it’s important to follow the correct steps in order to not undo the process which would result in a major problem in the test and production instance.

Example: Loss of data, sys_id not found

4 Essential Steps to Use Team Development

1. Set up the team development instance

• Use the same version on both sides to avoid conflicts
• Clone the target to the development instances
• Pull all changes from the parent instance
• Combine all changes from the parent instance to other instances

2. Grant access rights to the appropriate developers for each sub developer instance
3. Develop features on sub-development instances and track changes in the team dashboard

• Extract all the parent instance versions using Pull
• Compare versions in development instances (TDI). Reconcile if any conflicts appear

4. Move current version of records when the customization is ready to be pushed to the parent instance

About The Author

Raju Thelu works as an Associate software developer at V-Soft Digital. His expertise is in ServiceNow integrations, ITSM, and ITOM. He is a ServiceNow Certified System Administrator, Implementation Specialist, and Suite Certification - ITSM Professional and micro Certifications.