When using update sets, we need to remember what scope we are currently working in. Before we use any kind of scope in an instance, we are in the global scope, and before we create any update sets in an instance, we are in the default update set.

If we are not in a created update set, then we will also be in the default update set. However, there is a different default update set for each scope in a ServiceNow instance. This is important to know so that if you do switch scopes, then your update set automatically changes, as well.

We can see this change in the update set picker if we change the scope we are working on in an instance. In Figure 11.1, we can see an instance in the Global scope:

Because we are in the Global scope, the default update set selected for us is the default update set for the Global scope. We can see that this is shown to us by the ServiceNow instance by the text inside the square brackets in the update set picker.

If we change only the application, and, therefore, the scope, we can see the change in the update picker, too. Let's change the application to Guided Setup as an example, to see the change.

We can see these changes in Figure 11.2:

As you can see, the update set is automatically changed for us. This means that there can be a number of different default update sets in an instance, and each application will have its own.

The example brings us nicely on to another point about using update sets in different scopes. Each update set can only exist in a single scope. Before creating an update set, ensure that you are currently in the correct scope, so that changes you make can be added to the update set. Once created, ServiceNow security stops anyone from writing to the application field of an update set. This is set by a security rule and should not be amended.