Will importing objects from a dev instance to prod ever cause a conflict in sys_ids?

[HugoFirst]

I heard a presentation yesterday where a development team reported that they moved update sets from dev to test to prod, that they also imported XML files for the objects needed that are not in the update set.     I'm thinking that "import XML" could be used for new groups required for assignment groups in a new workflow, scheduled jobs, etc.   When I heard this, I thought that the XML file contains the sys_id as assigned on the dev instance ( or wherever the change was originally made ).        

My question is this:   Isn't there a risk that the sys_id of the imported object might already exist on the prod instance?   And   if not, what stops the prod instance from creating a duplicate sys_id for future objects?   I suppose that it's a small risk, but I would "sleep better" if I know that the prod instance can be relied upon to always generate a unique sys_id and that there is no chance of a duplicate being created or used.

[zica · Accepted solution]

Yeah you are right, it should be ( 16^32 ) * N, (32 for the fat that GUID is 32 digit), but still the number is loo large, I never wanted to be a friend with maths  

Yes i you are right that some customisations aren't take into a update set and you have to create them manually over instances, however as said, the number is too large that the probability of two accidently being the same is negligible.

However, update sets are not seen as a custo, but if you want them to push within an update set, there is share app that adds a UI Action you can use to manually push a job to an update set :

ServiceNow Share

It's called Add to Update Set Utility published by Ben Hollifield.

[HugoFirst]

I ran a quick test using the UI action mentioned in the article linked in your first reply.

It works great and is very cool!   Thank you for getting me on the right track!

[zica]

Thanks to Brad Tilton