how to resolve table object sys_id different in two instance?

[Community Alums]

Hi Experters,

We had a application push via update set from Dev to UAT, some of new table created by others and update are in default update set (the developer left our company), we following ServiceNow's advice to check his all changes- and make small change and back to capture those objects in a designated update set. However, when all are pushed to UAT, everything works fine, scripts built on and menus pull of data from these tables work fine. But we find the table objects have all different sys_ids than those in Dev.  We like you advice that:

1)will this has any negative impact later?

2)If need to fix, what is the best way to fix it,

3)One way we think is to back out all the update sets, then do it in a different way to avoid this,  any issue with that?

Thanks lot!

Jerry

[Bert_c1]

Hi Jerry,

I believe what you observe is expected. For tables (and related dictionary tables) the sys_ids will vary in stances as you promote update sets. and it has no impact on functionality as you found.  Once you promote the update set to production, then clone over sub-production instances, the sys_id values will then match among instances. Coalesce logic is not always on the sys_id for some tables. 

[Community Alums]

Bert_c1,

Thank you comments.  We resolved by backing out the update set, then doing it in different way.

Jerry

[Dipu Joy]

There are some tables that are not driven by sys_id where Coalesce strategies are imposed.

This KB is in a different context; but will give more information on this.

sys_id mismatch for sys_user_role