3 Mistakes I Made as a New ServiceNow Developer

[Nia McCash]

Updating the value of choice fields instead of the sequence

Many out-of-the-box choices (like the state field on the Incident record) have numeric values. The number value is what is saved to the database when you save a record with a particular state choice. 

 
If you want to change the order in which the choices are listed, update the Sequence of the choice, not the Value.

Forgetting to include data referenced by a configuration

Example: If you created a group in your development instance that you reference in a configuration (eg. an Assignment Rule), then you need to include the group in your deployment to production.  

If you forget to include the group, the configuration will not work as expected.  Remember, the group does not yet exist in production. 

In most cases, the configuration (eg. the Assignment Rule) will refer to the group’s sys_id. So creating a group in production with the same name will not solve this problem.

Ways to include a group (or any data not captured in your update set/application files😞 

• If you are working with a scoped application, you can create application files to include data.
   
• If you are working in the global scope, you can add the data in a couple of ways:
   
  1. Export the data (eg. the group record) via XML and import it into production so that the sys_id remains the same, since it is referenced in your configuration.
      
  2. Add the data to your update set, via this background script:
     

     var updateEntry = new GlideRecord('[TABLE]');
     updateEntry.get('[sys_id]');
     var update = new GlideUpdateManager2();
     update.saveRecord(updateEntry);​

Adding configurations to the wrong update set

This is a problem that happens to ServiceNow developers of all levels, including expert developers.

Here are some things that might help:

• Show update set picker in the header.
  
  
  
  

• Be careful when changing update sets in the same session but a different windows.
  Example: When you have multiple Chrome browser tabs open and you change the selected update set in one tab and forget to refresh the other tab. It would still show whatever update set you had selected when you loaded the tab but any changes you save would be made to the update set you most recently selected!
   
• Check update set entries religiously. This is a habit that I’ve gotten into that has been helpful for me. When I do development, I will often check the Customer Updates [sys_update_xml]  list (https://INSTANCE.service-now.com/nav_to.do?uri=%2Fsys_update_xml_list.do) to verify that the changes I’m making are being saved, and put into the correct update set.
   
• Tools, utilities, How-to guides - To re-iterate that this isn’t just a problem for new developers, there are various tools, utilities, and how-to guides that have sprung up from developers of all levels who have had to deal with this issue.  Here are just a few examples to get you started: 
   
  • Update Relocator by @Tim Woodruff/The SN Guys
     
  • Move to another update set by @andersfigenschow
     
  • Look at the various utilities provided on the Share site and you will see several that deal with update set management including this issue AND the one above. 

If you have other tools, tips, or links to how-to guides for Update Set management, please feel free to add them in the comments.

If you found this 👍helpful, please mark it as such below 👇

[Allen Andreas]

Thanks for giving some tips to beginner system administrators and developers! 🙂

One side note here...I wouldn't advise using a script to add "data" to your update set. Per the out-of-box functionality there's a reason why certain data records are not added to update sets (limited capacity for data transfer) and it's advised to export that and import it accordingly via XML, Import Set, or web service.

I'd reference documentation regarding this as well: https://docs.servicenow.com/bundle/quebec-application-development/page/build/system-update-sets/refe...

While technically, yes, smaller data updates such as a group record itself, may be fine to add to an Update Set through your script method or via a ServiceNow Share App, it's not technically the best practice to do this in general and you should keep this very limited in scope just for precautionary reasons and especially if the article, such as this, is around "mistakes", etc., haha.

Overall though, thanks for the tips!

Please mark reply as Helpful, if applicable. Thanks!

[Tim Woodruff]

Great article, @Nia McCash; 

As @Allen A helpfully pointed out, there's also a great deal of value in moving "data" into your update sets. Since you referenced one of my tools above (and even tagged me; thank you! ^_^), I hope you won't mind if I reference another: The global Include in Update Set tool.

This tool (linked above) is similar to other "include in update set" tools that are out there, except that it has a bit more state-handling, and - most importantly - doesn't require that you create a separate UI action for every table you want it to exist on. This tool makes the button available on all records that aren't already tracked in update sets (except for obvious tables you wouldn't want, such as task tables - and any other tables you choose to exclude). 

Thanks again for a great article! 

[Allen Andreas]

Hi,

Glad my reply above was helpful.

Definitely value in adding data to your update set in moderation, I do so as well, however, it would be amiss to not mention the documentation from ServiceNow and their own comments towards it. So that's what I did. Definitely kudos to the apps that have been built by ServiceNow enthusiasts that already help with this however, if it's going to be suggested to add data to an update set, it's better to use a "trusted" share app versus scripting as was mentioned in the article. So, overall, recommendation would be to adjust the article accordingly.

Thanks!