Typically when you see a “DELETE” in an Update Set it’s a bad thing. Either you didn’t mean to delete whatever it is deleting, or you’ve deleted a “brand new” element (something that was both created and then deleted in the new update set which does not exist in Test/Prod). For these reasons it is always a good idea to review your update sets prior to pushing them up to the Test instance to ensure that there are not any unexpected surprises lurking behind the covers.
Ok, now that we’ve discussed the usual scenario; it’s time for an edge case. In some rare cases you may actually want to delete something that exists in your other instances. One such use case would be that you have a field that is in the format of a “Glide DateTime” and you want it instead to be a “String” but you need to keep the name the same since there are a lot of other scripts referring to it. The system does not allow you to just change the type in the dictionary; instead you have to delete it and re-create the field as a “String”.
The problem is that by deleting the element and re-creating it with exactly the same name the system will record the DELETE and then when you re-create the field with the same name it will overwrite the DELETE with an “INSERT_OR_UPDATE” at which point you have now lost your previous DELETE update. When you try to then apply your Update Set to the target system it will throw an error “Cannot convert Glide DateTime field to type String…” and the Preview of that Update Set will fail. In this case, the workaround to this issue is to record your DELETE in a separate Update Set which will be applied first, then record your INSERT_UPDATE in another Update Set to be applied afterwards. By doing it in this manner the system will not overwrite the DELETE and therefore the Preview and commit on both Update Sets will now succeed. Hopefully you never run into this scenario but I hopefully it will save someone some head scratching at some point.