How many records can be captured in an Update set as a ServiceNow Best Practice

[nitheshkumar74]

Hi,
If I have large number customer updates to capture and in my update set version1, customer update records exceeds 100 or 200, do I need to create a new version or all the customer updates need to be captured in single update set version, (example if there is 1000+ records)? which is the ServiceNow best practice.
Will there be any performance or maintainability issue if large records gets captured in single version during migration of update set to higher environment?

[Dr Atul G- LNG]

Hi @nitheshkumar74 

Based on my knowledge and experience, it's not about how many changes you capture, but rather about creating updates based on each story. Each story might involve 200-400 changes if done correctly.

If you create one update set for all work, it will become cumbersome and could create issues during movement or merging with other developments. It's better to keep it story-wise to avoid these complications.

[Robbie · Accepted solution]

Hi @nitheshkumar74,

Expanding on from what @Dr Atul G- LNG has outlined. An update set in an ideal world should be built on the premise of a Release package and functionality. 

An update set can easily manage 1000 plus update records, however, just because it can, it doesn't mean it should.

If you change the mind set around the potential need to rollback a piece of functionality or an update set, this will drive the grouping and contents of an update set - Always ask yourself, what happens if I need to roll back this change.

@nitheshkumar74 - Please also note the 'Parent' field available on the update set table. This allows a 'Batching' (Grouping) of update sets where you can logically split and split functionality into a release.

To help others (and for me to gain recognition for my efforts), please mark this response correct by clicking on Accept as Solution and/or Kudos.

Thanks, Robbie

[jcmings]

Like the other commenters have mentioned, best practice suggests you should be breaking up your work into smaller chunks (often referred to as stories). This will help you stay organized and will help testers validate functionality. For instance, if you have an objective of creating a catalog item, back-end form, and a business rule, it would make sense to break up the objective into three separate stories: one for building the catalog item, one for your form layout, and one for setting up your business rule. A tester could then validate each story on its own and then you can know exactly what you may need to change.

To answer your question though -- generally, a larger number of records will be fine during migration. It may take longer to preview your update set and commit it, but that's not that big of a deal. From a maintainability perspective, it would benefit you in the future to break up your objective into smaller tasks (stories).