How to create a batch update set in ServiceNow

[Mohammed Kemal]

Batch Update Sets

Case Scenario: 

If you have multiple developer working on the same application it's hard to decide which should go first or not. At time like this the best way is to create a batch update set and let ServiceNow determine organizing the update sets hierarchically by resolving some of the issues it may arise from moving updates from instance to instance.

Batch update sets enable you to group update sets together so you can preview and commit them in bulk.

I can see that dealing with multiple update sets can lead to problems, including committing update sets in the wrong order or inadvertently leaving out one or more sets. You can avoid all of these problems by just grouping your completed update sets into a batch.

What's the cool things here is that the system organizes update set batches into a hierarchy for you. One update set can act as the parent for multiple child update sets. A given set can be both a child and parent, enabling multiple-level hierarchies. One update set at the top level of the hierarchy acts as the base update set.

When you preview or commit the base update set, you preview or commit the entire batch. The system determines the processing order, and checks for collisions, based on the dates the changes were recorded, and on their sequential ancestry. Their ancestries are the specific instances in which the changes in the update sets took place.

Here are the step by step instruction: 

1. Finish the development the one you started now and complete the update set.

2. Filter out the update set related with your development by using column filter

3. Include an update set in a batch by specifying another update set as its parent.

4. Select the record for an update set that you want to include as a child in the batch.

5. On the Update Set record, navigate to the Parent field and select the update set to act as the parent.

6. Click Update.

The system returns you to the list of Update Sets. If the Parent column is visible, it shows the parent for the newly-created child.

Whenever you ready to export batch update set you will go to the "Local Update set" and locate the batch update set. Once you open it go to the related links and click "Export Update set batch to XML"

 

One thing you should bear in mind is that you cannot separately commit an update set that is a child in a batch. You must commit the entire batch by committing the batch base. If necessary, you can remove the child update set from the batch by editing its record's parent field.

 

You can also click Visualize update set batch to see the update sets in a graphical way with their name.

Click Helpful, if this help you in anyway and here 👇 is how you can Bookmark the article for future easy access.

Thanks,

Mokemal!!

[Lubaba]

Hello Mokemal,

This is helpful, thanks for sharing!!

Q. Do all the update sets have to be in the same application scope to put them in a batch update set?

[Akanksha Gupta2]

Thanks for this Article .!!

Can you pls tell me what is the difference between normal update set and Batch update set ?

[Mohammed Kemal]

Hello Akanksha,

You are very welcome!!

The difference between normal update set and Batch update set are as follow 

1. Batch update set contain more than one update set

2. Batch update set saves time than moving individual update sets from instance to instance

3. In Batch update set if the system found problems, you can click the Preview Problems for Batch and resolve the problems as you normally would for any update set. When you have resolved all the problems, click Run Preview Again for Batch.

Thanks,

Click Helpful, and Bookmark if this help you in anyway!

Thanks,

Mokemal!

[Community Alums]

Hi Akanksha,

Please refer to the below links for reference.

For Normal Update sets:

https://docs.servicenow.com/bundle/kingston-application-development/page/build/system-update-sets/task/t_MergeUpdateSets.html

For Update set batching:

https://docs.servicenow.com/bundle/kingston-application-development/page/build/system-update-sets/hier-update-sets/concept/us-hier-overview.html

Please Mark Correct and Helpful if you find my response worthy based on the impact.

Thanks & Regards,
Vaikrant Ghatge
ServiceNow Developer

[Mohammed Kemal]

Thanks, Vaikrant! For sharing the links!! 

[Mohammed Kemal]

Hello Lubaba,

You are welcome!

To answer your questions in short yes. It need to be all in the same application scope. If your batched update set contain changes from different application than your batch it will not let you commit. It shows an error message. 

At time like this, create a different update set and move those changes into the update set you created. That way you can move and commit the changes.

I hope I answered your questions and click helpful if you think so!

Thanks,

Mokemal!!

[Ashadiee]

I have created a batch update set but cannot commit when I try. I have update from the Global mixed. How can I fix this?

[Mohammed Kemal]

Hello,

Can you share a screenshot of what the error says?

As you said this may be because of the mixed application scope. Check your changes if they all belong to the same Application. If not create a different update set one for the Global and push those into the new one. 

thanks!

[Lubaba]

thanks, fixed. It was certainly from the mixed application scope.

[sonali panda1]

Hi, Why can't we create a Global update set and add all the update sets from different scope there? Shouldn't it eliminate the cross scope issues? I remember having done this in past.

[Allen Andreas]

Hello,

Just saw this, but no, all of the update sets in a batch DO NOT have to be in the same application scope.

It's extremely common to create a global parent update set to house all the batched update sets and those batched update sets can be from any number of scopes. So set 1 can be from CSM, set 2 from VA, set 3 from SecOps, etc. all associated to the parent update set just fine.

Any single update set CAN NOT contain updates for another scope, but the question was:

"Q. Do all the update sets have to be in the same application scope to put them in a batch update set?"

And that answer is...no, they don't have to be in the same application scope to put them in a batch update set.

Please mark reply as Helpful, if applicable. Thanks!

[sonali panda1]

I agree to this. A Global Parent update set can be used for holding all other application scopes update sets. 

[spietrofeso]

Looking for guidance on best practice regarding batching update sets:

In Production, completed update sets have been retrieved  into Production.

In Production, can I create a Parent Update set in Global and add in the retrieved update sets?

When I do this, the Parent will be in a state of In progress and I assume the child update sets will stay in the state of Previewed.

I will be adding in update sets from different Applications into this Parent Update Set

When I am done adding in child update sets, I set Parent to Complete and then run Preview and then Committ, 

Thanks in advance

[Allen Andreas]

Hi @spietrofeso 

Ideally, this would all be done in the sub-production environment. When development finally goes to Production, it should be organized into batched update sets, commonly stated as a "release set for x" or "deployment set for y", and that is what you preview and commit (that parent).

It's not recommended to be moving up singular sets, all scattered, and then batching them in Production.

[spietrofeso]

@Allen Andreas 

I agree with you Allen but I am in a shared development instance and other Devs ran the retrieval already.

That was my plan to create Parent update set with a release naming convention in test and move up but they are already retrieved.

Can I create the Parent update in test and add completed test update sets, set parent to complete and then retrieve or though it may not be best practice to create the batch in Prod - will it cause any issues of we do that?

[Allen Andreas]

Hi @spietrofeso 

That's usually why the retrieve update set feature isn't always a good thing and then add in a shared environment like what you have and that definitely makes a case for people only promoting their own work, not all "completed" sets.

In any case, it sounds like we're past that point. So, now that everything is on Prod, but in a non-committed state, you may be able to take all those other sets and set the parent accordingly, then, when you conduct the preview, it'll operate as you'd like taking into account reviewing the latest update to a common record across multiple sets, etc.

If my reply above helped, please consider marking it as Helpful and/or Accept Solution, if applicable. Thanks!