Are the customer updates within the Default Global Update Set lost when creating a new Update Set?

[EagerBeaver]

Hello SysAdmin Forum,

First time ServiceNow user here, so apologies if this is covered in some University modules I haven't seen yet.

I've got a new Personal Developer Instance that I'm doing some lab exercises in, and was wondering what is best practice for regularly creating and committing update sets. I have been told that update sets are a great way to consolidate changes made within an instance - and would like to have a go at doing this myself.

However, I have noticed a Default Global Update Set created by the system. This contains 200+ customer updates which I assume are generated on PDI creation as all the date timestamps are exactly the same.

My question is - do I need to do anything with this Default Update Set before creating a new Update Set? I am concerned I will lose these updates if I create a new Update Set without committing what is currently in the Default Update Set.

Reading the product documentation, it seems this Default Update Set must always exist - so I'm hesitant to make any changes or interfere with it.

If anyone has any advice on best practice or approach to update sets, I'd really appreciate it.

Thank you!

[Dr Atul G- LNG · Accepted solution]

Hi @EagerBeaver 

My question is - do I need to do anything with this Default Update Set before creating a new Update Set? I am concerned I will lose these updates if I create a new Update Set without committing what is currently in the Default Update Set.

Atul:

No worries if nothing has been captured in the default update set. However, if by mistake any developer has added something to the default update set, it’s better to move those changes to the new update set and keep the default update set as it is.

Please do not delete or remove the default update set.

[Roshnee Dash]

• The Default Update Set is a system-generated container that captures all changes made when no other update set is selected. It is essential and cannot be deleted.

  Why You Shouldn't Commit the Default Update Set

  • It often includes baseline configurations created when your PDI was initialized.
  • It's not intended for migration between instances.
  • Committing it may lead to unintended consequences due to irrelevant or system-level changes.

  Best Practice: Use a Custom Update Set

  1. Create a New Update Set

     • Navigate to System Update Sets > Local Update Sets.
     • Click New, give it a meaningful name (e.g., IncidentFormChanges_May2025), and set it as current.

  2. Make Your Changes

     • All tracked changes (e.g., form edits, business rules) will now be captured in your custom update set.

  3. Review and Commit

     • Regularly check the update set to ensure it contains only the intended changes.
     • Once complete, mark it as Complete and Commit it if you plan to move it to another instance.

  Moving Changes from the Default Update Set

  If needed, you can move updates from the Default Update Set to another:

  1. Go to System Update Sets > Customer Updates.
  2. Filter by: Update Set is Default.
  3. Select the updates you want to move.
  4. Click the Actions on selected rows menu.
  5. Choose Move to Update Set and select your target update set.
  6. Confirm the move and verify the updates in the new set.

[Roshnee Dash]

@EagerBeaver 
If you find this response valuable, kindly consider marking it as 'Accept as Solution' and 'Helpful.' Your acknowledgment not only assists the broader community but also supports my contributions.

[EagerBeaver]

Thank you both @Dr Atul G- LNG & @Roshnee Dash for your replies - both were helpful.

I have accepted a solution - and I appreciate the swift response!

Thanks again!

- EagerBeaver