Numbering Existing Records

//Numbering Existing Records

Numbering Existing Records

The number maintenance module allows you to manage all of the numbering for the various tables within ServiceNow. Record numbering really isn’t that difficult to deal with and its very simple to understand as long as you get it set up before the table has records in it. If you have a table with a bunch of data already and you want to assign numbers or IDs to the records in that table, then you need to run a script to assign numbers to all of the existing records along with the typical number maintenance setup. This article explains how to set this up. Thanks to Matt Gaide and Paul Murphy for the script and article idea!

1 Create a new field to store the number or ID

2 Create a new ‘Number Maintenance’ record

3 Run the Script

Navigate to ‘System Definition -> Scripts – Background’ and paste and run the following script.

Note that this script assumes that you are adding numbers to a field called ‘u_number’ on the ‘sys_user_group’ table. As your table and field names will most likely differ from these, you’ll need to replace the instances of ‘sys_user_group’ and ‘u_number’ with the names of the table and field in your situation.

var rec = new GlideRecord('sys_user_group');
rec.addQuery('u_number','');
rec.query();
while(rec.next()){
   rec.u_number =  new NumberManager(rec.sys_meta.name).getNextObjNumberPadded();
   rec.setWorkflow(false); //Do not run business rules
   rec.autoSysFields(false); //Do not update system fields
   rec.update();
}
By | 2018-07-09T15:22:23-06:00 April 27th, 2010|Categories: Scripting|Tags: |2 Comments

About the Author:

2 Comments

  1. Mike Flora October 4, 2010 at 1:42 am - Reply

    Do you see any ill-effects of domain separating the sys_number table in an MSP environment?

    Thanks

  2. Mark Stanger October 4, 2010 at 2:01 am - Reply

    You might get a better response to this on the forums, but I’ll give you my opinion. My first thought is that you’ll still have users living in the global domain. For these users, you will have tickets with duplicate numbers that they will have to sort though — unless you set up your number separation so that each version of numbering on a table would have a different prefix or something. Even if you chose that route, it could be a nightmare to manage.

    My second thought is that you’ve got an infinite supply of numbers for any given table. Because of this, there should be no need to further confuse the issue by domain-separating that table. A lot of people (maybe not you) get hung up about wasted numbers and numbers not following an exact sequence but I have yet to hear a real compelling argument for preventing ‘number waste’ :).

    I’ve never tried to do what you’re asking about (somebody on the forums may have) but I can see some potential issues with doing it and see no reason to believe that domain-separating the sys_number table would provide a real benefit. If it were me I’d just make sure that my numbers had enough padding to not run out and forget the separation.

Leave A Comment