Hi
Each and every best practice is covered in this article
Update Set Best Practices
Here are the best practices I’ve compiled for using update sets and seamlessly migrating data from one instance to another.
Over the years, I’ve had my struggles with update sets. While useful, I haven’t seen a whole lot of guidance around them. I have also seen them utilized in slightly different ways at every company I’ve worked for. While I don’t know if these are industry standards or legitimate best practices (ok, so the title might be a bit click-baity. Sorry!), I’d like to share this article with you containing all the best tips and tricks I’ve picked up over the years.
**Disclaimer: These are the guidelines and recommendations I personally recommend based on my experience. It is in no way an official guide endorsed by anyone other than myself. That being said, these tips have consistently served me well and I strongly believe it is a solid update set implementation strategy.
Throughout this article I use the terms migration and promotion interchangeably in regards to update sets. When I use these terms, I mean pulling an update set from one instance to another and previewing then committing it.
One update set per user story
Keep the number of updates per update set small
Don’t merge update sets
Specify update set order
Update set naming convention
Publish workflows before completing an update set
Check all updates before migrating
Never delete updates, instead move them to Default
Update set migration order
Promote changes after hours or on weekends
One Update Set Per User Story
I always liked the approach of aligning update sets to user stories. The rule of thumb is to create one update set for each user story. Using this method helps organize updates made by their functional components. It also helps keep the number of updates within each update set to a manageable count. I always feel a little uneasy migrating update sets containing a large number of updates to another instance of ServiceNow, which I will explain in the next section…
Keep the Number of Updates per Update Set Small
Leading off of the previous section, I don’t like update sets containing a large number of customer updates for a couple reasons:
Update sets become convoluted
If you are trying to remove unnecessary updates from an update set, it is much easier to identify these updates when there are only a few entries to go through.
Troubleshooting update set conflicts becomes much more difficult
With large update sets, it becomes an inevitability that conflicts will arise. Especially when you have multiple developers on your team all making changes to the same instance. Of course there are exceptions to this, such as when developers are working in different application scopes or are using team development. If this bullet point doesn’t apply to your team you should disregard this point.
I don’t have a hard rule of thumb for the maximum number of updates an update set should contain, but things seem to get more difficult when the update count passes 100, and especially difficult when it passes 1,000. If you follow the “one update set per user story” guideline, you should rarely, if ever, have more than 1,000 updates in an update set. If you find your update sets having more than 1,000 updates on a consistent basis, you probably should go back and rework your stories so they are more granular. If this isn’t an option, you might consider splitting large update sets into smaller parts.
Don’t Merge Update Sets
…unless you have a good reason to!
This may be a controversial one, but I’ve found more issues merging update sets than keeping them separate. One of the reasons is because of the point above about limiting the number of updates in an update set. Even though merging takes the most recent update if there are multiple updates to the same record, I have still found plenty of other conflicts with merged update sets, and having such a large number of updates to comb through can quickly become a nightmare. Especially if you are working with multiple developers and need to know who and what story the conflicting update belongs to.
If you’re going to merge update sets, be sure to take an XML backup of all your update sets you will be merging before doing so. To learn how to export records to XML, check out this article.
You may be asking the question “if I don’t merge my update sets, how can I ensure the most recent update to a record is applied?”. That’s a good point, and if you don’t merge and commit update sets in an arbitrary fashion, you’ll most likely receive the Error: Found a local update that is newer than this one error.
To get around this…
Specify Update Set Order
Ordering update sets will help mitigate the risk of receiving errors when previewing update sets in another instance. What I usually do is order my update sets by Completed on field. I simply put the ordering as text in the Name field come migration time. The update set name column will usually look something like the following:
Prefixing the name of the update set with a number ensures proper tracking even in the event an update set is re-opened and then completed again. This method does have its drawbacks. You will occasionally run into conflicts, but using this method along with the other tips provided in this article will make the task of troubleshooting much easier.
Another method I’ve seen documented but have not used is Update Set Batching, which I believe was introduced with the Jakarta release: https://docs.servicenow.com/bundle/jakarta-application-development/page/build/system-update-sets/hie...
If anyone has used this method and can attest to its effectiveness, please let me know in the comments!
Prefixing the name of the update set with a number ensures proper tracking even in the event an update set is re-opened and then completed again. This method does have its drawbacks. You will occasionally run into conflicts, but using this method along with the other tips provided in this article will make the task of troubleshooting much easier.
Another method I’ve seen documented but have not used is Update Set Batching, which I believe was introduced with the Jakarta release: https://docs.servicenow.com/bundle/jakarta-application-development/page/build/system-update-sets/hie...
If anyone has used this method and can attest to its effectiveness, please let me know in the comments!
Update Set Naming Convention
There are a lot of different methods for standardizing and agreeing upon a naming convention. The one I use which seems to work well is the following:
— —
Example: Derek — STRY0001001 — Email Notifications
I put this in the Name field. This tells us who the update set belongs to, the story it encapsulates, and a brief description of what the update set is capturing. By all means if you have a naming convention that works better for you, go for it! There’s no one-size-fits-all, and your organization may require a different set of rules or you may find that this naming convention doesn’t work for you.
Publish Workflows Before Completing an Update Set
Always make sure to publish checked-out workflows before completing and migrating the update set the workflow changes are captured in. It’s easy to miss but if you don’t publish the workflow, the changes do not get captured in the update set.
— If you forgot to publish the workflow and have completed the update set in your Dev instance but have not yet migrated it to your Test instance, you can set the update set back to “In Progress” and publish the workflow, then set the update set back to “Complete”.
— If you forgot to publish the workflow and have completed the update set in your Dev instance and have already migrated the update set to your Test instance:
You can create a new update set specifically to publish the workflow and then migrate that to your Test instance.
Alternatively:
You can back out the changes in your Test instance > set the update set back to “In Progress” in your Dev instance > publish the workflow > then set the update set back to “Complete” and re-migrate the update set to your Test instance.
Check All Updates Before Migrating
Remove Unnecessary Updates
Making sure your update sets are cleaned of any unnecessary customer updates before setting your update set to complete sets you up for a headache-less migration. The last thing you want is for errors to crop up while previewing your update set and not remembering if the record modification in question is something you wanted to apply or skip. Culling unnecessary customer updates from your update set upfront helps mitigate this risk and can save you some hassle.
Once Again, Keep Update Sets Small
This goes hand-in-hand with keeping update sets small, as larger update sets will be more difficult to sort through. Some changes could have been from days, weeks or even months back. This can happen when an update set is opened and record modifications are made, but priorities shift and you need to switch gears to work on something else. Once you come back to your original update set you may have forgotten what the old record modifications were for.
Never Delete Updates, Instead Move Them to Default
As with most records in the system, never delete customer updates. If you want to remove updates from an update set, instead it is recommended to move them to the default update set. You never know if you’ll need to retrieve the information contained in the update at a later date. It’s best to have it just in case.
Update Set Migration Order
In a typical setup, a company will have a Development, Test (also known as QA or sometimes UAT), and a Production instance.
The method I’ve found which works best for me and my team is to develop everything in Dev, then when it is time, migrate the update sets to Test. Preferably, any issues found in Test either by the developer or QA team should be corrected in a new update set in Dev and migrated to Test. I like to use the following naming convention for any fixes:
- -
Example: Derek — STRY0001001 — Email Notification Fixes 1
Once the fix is in Test, the fix should be tested to make sure the functionality now works as intended. If more issues are found, the process should repeat. Fix in Dev > Promote changes to Test > Test functionality.
“Fix” Update Set Numbering
Don’t forget to prefix the update set name with a number. I like to add fixes after the last update set I am planning to commit unless it needs to be promoted earlier due to errors in subsequent update sets which the “Fix” update set can resolve. In this case I prefix the update set name with the following:
- — -
Example:
1) Derek — STRY0001001 — Email Notifications
1a) Derek — STRY0001001 — Email Notification Fixes 1
Promoting to Production
Once the fixes are done and all test cases have passed, the update sets can be promoted to Production. It’s important to do a check in your Production instance to ensure as much functionality is working as possible. If possible, do not create records in Production for testing purposes, and do not perform any actions that would trigger email notifications to go out or do anything that could adversely affect end users in the system. Some companies will allow maintenance windows where the system will be locked from end user access for a period of time. If so, you may have more flexibility in what you can test. For example, you may be able to disable email sending during the maintenance window to test the functionality works correctly. Once testing concludes, you can delete any test emails and records that were created and enable email sending again.
**Note: Be careful in Production. Most companies don’t appreciate end users being impacted during/after code migrations or maintenance windows. It’s usually not the end of the world if a rogue email goes out to an end user but it’s not something you want to risk if you can avoid it.
Promote Changes After Hours or on Weekends
In line with the previous point on promoting changes to Production, it’s a good idea to schedule releases or large code migrations to Production during company down-time, namely after hours or over a weekend. This will give you some time to catch things that go wrong and fix them before users come in to work and start using the system. The name of the game is to minimize the potential negative impact your changes could have on anyone using the system.
And there you have it! Those are my update set best practice guidelines. I hope you’ve found some or all of these tips helpful and have taken some of the mystery out of update sets. I wish you the best of luck in your update set journey.
Let us know if there’s anything we missed or you would like us to expand upon in the comments!
At the time of this writing, we are on the London release. The information presented in this article may not apply to your instance if you are on a different version of ServiceNow.
Please mark my answer correct and helpful based on impact
Thanks in advance
Saurabh singh
