Symptoms
Two records from different tables with the same name is causing ambiguity
Release
All available releases
Cause
The number maintenance in the instance could be different from OOB ones. In out of the box instances, no two table would share the same prefix. Say prefix for the table task is TASK, SCTASK for catalog tasks, CHAT for chat queue entries etc. It might have been modified in the instance. Since these records are auto numbered this is expected. The user can verify the same by navigating to the following link and checking the prefixes for the tables.
https://<instance-name>.service-now.com/sys_number_list.do
Resolution
In order to resolve the issue, the user need to have unique prefixes set for the affected tables. They can set the out of the box prefixes to avoid other ambiguities. TO change the same, the user will need to edit the prefix values for the corresponding tables by going to the sys_number table.
In order to change the prefix of the existing records, one can make use of the following code in the background script.
For example, to change sc_task records' prefix from TASK to SCTASK, the following script can be used.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
//Query for the table records
var rec = new GlideRecord('sc_task');
rec.query();
while(rec.next()){
//Change the number prefix from 'TASK' to 'SCTASK'
rec.number = rec.number.replace('TASK', 'SCTASK');
rec.setWorkflow(false); //Do not run business rules
rec.autoSysFields(false); //Do not update system fields
rec.update();
}
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Additional Information
Please DO NOT run the script on the production environment directly. Please test it on a developer instance first to see the working of the script and then you can try it on one of the sub-production instance. Only after verifying this is working as expected, you may proceed to execute this in production.