choice list with different sys ids but same values servicenow

[Khanna Ji]

I have modified choice values of category field on Incident form on Dev and manually added those values on Prod since there were very less number of choices.

Now I have added/modified 20+ choices in category and sub category on Dev and planning to move them through update sets.

My understanding is that, choice list works on value not on sys id. When I commit the changes on Prod, it will replace the entire choice list values with new values from Dev without impacting already existing choices since it works on Values not on sys id.

Is my understanding correct?

[Khanna Ji]

Give it a try. Manually add a new value on test and Dev. Both are same but will have different sys ids. Now move the changes done in dev to test through update set. It will delete the value that you had and recreate it with a new value from dev with same sys id.

So here, either sys id is getting updated or value is deleted and new record is created.

[Brian Lancaster]

I just tried it with incident state between my personal dev and my co-works.  It did work like you say so it must be checking the sys_id first and then checking the value.  However I would not recommend doing it this way.  This is against best practice and if there is a bug in the a future release it may not work. 

[Khanna Ji · Accepted solution]

Nice, this is the learning attitude. I am very much thankful and appreciate your comments. Not much people agree with others. You tried it and confirmed.

I agree with you that it is not a best practice but ServiceNow is a beautifully designed tool which handles all the conflicts.

In case of Choice list, it simply deletes the existing records and imports the new choices. So, sys id does not matter here and only the value that is counts since choice list fields only care about values 🙂

[VigneshMC]

You are partially right with the term " ServiceNow is a beautifully designed tool which handles all the conflicts", as its based on sys_id's on all most all places in service-now. By wiping out all values and adding them again with all values which was present when the update were captured, there is a very good chance that we may end up adding some test values from dev (most dev instances have junks). Its much easier to check the update set for individual choice values rather than going through an xml with choices especially when you have hundreds of them.

Thanks

[Brian Lancaster]

The values are only for the system when it comes to what you look at in your code.  When it comes to records being created / modified in update sets the system uses the sys_id not the value.