Update Scan Results link to record

[Jeanne Goodman]

Thank you, in advance for your help with this. I've been thrown into a situation that is making me learn everything there is to know about SNOW on the job.

Below gives the problem. But since I didn't think I could describe what I'm doing properly, I created a video that's a just a couple minutes long that shows the problem.

This is the video https://youtu.be/MACULrfJldQ 

[Mark Manders · Accepted solution]

PLEASE

Can you start with learning that SNOW is a completely different software platform than ServiceNow? I know lots of people use Snow to shorten ServiceNow, but it's a completely different product/company. I have worked with/for companies using both and it gets very confusing when some says 'Snow' while meaning ServiceNow. 'SN' would be a better abbreviation. 

TIP to learn
That being said: I see you are just deleting it from your update set, without validating what is going on. I suspect that you made an update to an object and someone else did the same and those two are now colliding, giving the error on your scan. How do you know that the config you need is also included in the update someone else made? Let's say the condition was 'active = true' and you added 'category = hardware' because you need it to run on active records on category 'hardware'. Someone else came in and thought 'I need this on all hardware' and removes the 'active' part. You delete your update from the set, without checking if your config has already been release, or if it has been removed.

Answer to question

For the searching part: open the sys_update_xml table and just look there for the sys_id's. Reason for looking there: it will show you the other update sets in which your objects were changed. You know who it was, when and maybe even why, if update sets are well documented.

[Jeanne Goodman]

Thanks for the correction and the suggestion. The reason I know it's not someone else is because I'm the only one making the updates.
Since I'm still learning what I'm doing I end up with multiple update sets for the same thing. Sometimes it's because the catalog builder creates an update set every time I make an edit in there. Sometimes it's because I pushed from Dev to Test, discover an issue and create a new update set in Dev. Then I merge the two update sets before pushing to Test again. Is that bad practice?

I will use the sys_update_xml table going forward, but copy paste is the correct way to do the search? No hidden links somewhere to get the same results?
Thanks again for your help.

Jeanne

[Mark Manders]

Unfortunately, no hidden links. Just look for them in the sys_update_xml list.

Related to your update sets: if you are creating multiple update sets for the same functionality, batch them. If you create a parent update set that you set in all the childs, you can set your parent to 'complete' when you are ready and move it to the next instance. It will take all your child update sets with you and the best thing is: if you have made changes to the same business rule in 5 update sets: if they are committed as batch, only the most recent version of that rule will be commited. (you can also batch update set from different scopes together).

If you see you missed something on TEST and go back to dev, best thing to do is to create a new update set, apply your fix and move just that update set to test. There you make it a child of your previous update set and when moving to PROD, it will all be moved at the same time, committing only the latest version of the object you fixed.
Merging them is also a solution, but you will be moving everything over and over again, which isn't necessary. Just move the fix.