Update Set

                                                      ServiceNow Interview Questions

                                                                  Update Set

1. What is an Update Set in ServiceNow?

An Update Set in ServiceNow is a group of customizations that can be moved from one instance to another. It captures changes made to applications and configurations, such as form layouts, business rules, client scripts, and workflows. Update Sets are used to transfer these changes between development, test, and production environments.

2. What are the limitations of Update Sets?

Limitations of Update Sets include:

They do not capture data changes, only configuration changes.

Certain elements like homepages, scheduled jobs, and users/roles are not captured.

Update Sets must be manually committed in the correct order to avoid dependency issues.

Conflicts can arise if multiple Update Sets modify the same object.

3. How do you move an Update Set from one instance to another?

To move an Update Set from one instance to another, you can:

Mark the Update Set as “Complete” in the source instance.

Retrieve the Update Set in the target instance by navigating to System Update Sets > Retrieved Update Sets and clicking “Import Update Set from XML” or using the “Retrieve Completed Update Sets” option.

Preview and commit the Update Set in the target instance to apply the changes.

4. What are the best practices for using Update Sets?

Best practices for using Update Sets include:

Using meaningful names and descriptions for Update Sets.

Regularly committing Update Sets to avoid large, unmanageable sets.

Testing changes in a sub-production environment before committing them to production.

Avoiding overlapping changes in multiple Update Sets to prevent conflicts.

5. How do you handle conflicts in Update Sets?

Conflicts in Update Sets can be handled by:

Reviewing the conflicting updates during the preview stage.

Manually resolving conflicts by choosing the appropriate version of the object.

Using the “Merge Update Set” feature to combine changes from multiple Update Sets into a single set.

6. What is the difference between a normal Update Set and a batch Update Set?

A normal Update Set is a single entity that captures changes and can be committed separately. A batch Update Set allows you to group multiple Update Sets together, enabling you to preview and commit them in bulk. This helps manage dependencies and ensures that related changes are applied together.

7. How can you move a particular change from one Update Set to another?

To move a particular change from one Update Set to another, open the Update Set and locate the specific Customer Update record. Change the Update Set reference field to the desired Update Set. This will move the change to the new Update Set.

8. What are the steps to set an Update Set as the default?

To set an Update Set as the default, navigate to System Update Sets > Local Update Sets, open the desired Update Set, and set the “Default Set” field to true. This makes the Update Set the default for its scope, and the system will set “Default Set” to false for all other Update Sets in the same scope.

9. Scenario: You need to ensure that changes made by different developers do not conflict when merged into a single Update Set. How would you manage this?

To manage this, I would implement a strategy where each developer works on their own Update Set. Once their changes are complete, I would use the “Merge Update Set” feature to combine the individual Update Sets into a single set. During the merge process, I would carefully review any conflicts and resolve them by choosing the appropriate version of the object. Additionally, I would ensure that developers communicate and coordinate their changes to minimize conflicts.

10. Scenario: You need to move a large number of changes from a development instance to a production instance. How would you ensure that all changes are captured and moved correctly?

I would create multiple Update Sets to capture the changes, ensuring that each Update Set is focused on a specific set of related changes. I would regularly commit and test these Update Sets in a sub-production environment to ensure they work as expected. Once all changes are verified, I would retrieve and commit the Update Sets in the production instance, following the correct order to avoid dependency issues.

11. Scenario: An Update Set contains changes that should not be moved to the production instance. How would you handle this situation?

I would review the Update Set and identify the changes that should not be moved. I would then create a new Update Set and move the unwanted changes to this new set. This can be done by editing the Customer Update records and changing the Update Set reference. Once the unwanted changes are isolated, I would proceed with moving the original Update Set to the production instance.

12. Scenario: You need to ensure that an Update Set is applied in a specific order to avoid dependency issues. How would you achieve this?

I would create a batch Update Set to group the related Update Sets together. This allows me to preview and commit them in the correct order, ensuring that dependencies are resolved. Additionally, I would document the order of the Update Sets and communicate this to the team to ensure consistency during the deployment process.

13. Scenario: You need to track the changes made by a specific Update Set after it has been committed. How would you do this?

I would navigate to System Update Sets > Local Update Sets and open the committed Update Set. From there, I can view the list of Customer Update records associated with the Update Set. This provides a detailed history of the changes made, including the specific objects and fields that were modified.

14. Scenario: You need to revert changes made by an Update Set that has already been committed. How would you handle this?

To revert changes, I would first identify the specific changes made by the Update Set by reviewing the Customer Update records. Then, I would manually revert the changes by restoring the previous versions of the affected objects. If necessary, I would create a new Update Set to capture these reversion changes and commit it to ensure the instance is restored to its previous state.

15. Scenario: You need to ensure that an Update Set is only applied to specific instances and not others. How would you achieve this?

I would use the “Update Set Tags” feature to tag the Update Set with specific instance names or environments. This helps in identifying and filtering Update Sets that are intended for specific instances. Additionally, I would communicate with the team to ensure that the Update Set is only retrieved and committed in the designated instances.

16. Scenario: You need to ensure that changes made in a development instance are not accidentally moved to production. How would you manage this using Update Sets?

To manage this, I would implement a strict process for handling Update Sets. This includes:

Using naming conventions to clearly identify Update Sets intended for different environments.

Regularly reviewing and validating Update Sets before marking them as complete.

Using the “Preview” feature in the target instance to identify any potential issues before committing the Update Set.

Implementing access controls to restrict who can retrieve and commit Update Sets in the production instance.

17. Scenario: You need to track the progress of multiple Update Sets being developed simultaneously. How would you achieve this?

I would use the “Update Set Progress” feature in ServiceNow to track the status of each Update Set. This feature provides a summary of the changes captured, the current state of the Update Set, and any conflicts or errors. Additionally, I would hold regular meetings with the development team to review the progress and address any issues.

18. Scenario: You need to ensure that an Update Set is applied only after a specific prerequisite Update Set has been committed. How would you handle this?

I would create a batch Update Set that includes both the prerequisite Update Set and the dependent Update Set. This ensures that the prerequisite Update Set is committed first, followed by the dependent Update Set. Additionally, I would document the dependency and communicate it to the team to ensure the correct order is maintained during the deployment process.

19. Scenario: You need to revert a specific change made by an Update Set without affecting other changes. How would you achieve this?

I would identify the specific change by reviewing the Customer Update records in the Update Set. Then, I would manually revert the change by restoring the previous version of the affected object. If necessary, I would create a new Update Set to capture the reversion changes and commit it to ensure the instance is restored to its previous state.

20. Scenario: You need to ensure that an Update Set is not committed if it contains errors or conflicts. How would you manage this?

I would use the “Preview” feature in the target instance to identify any errors or conflicts before committing the Update Set. The preview process highlights any issues that need to be resolved. I would address these issues by reviewing the conflicting updates and making the necessary adjustments. Only after resolving all errors and conflicts would I proceed with committing the Update Set.

21. Scenario: You need to move changes from a scoped application to another instance. How would you handle this using Update Sets?

I would create an Update Set within the scoped application to capture the changes. Once the Update Set is complete, I would mark it as “Complete” and retrieve it in the target instance. I would then preview and commit the Update Set in the target instance to apply the changes. It is important to ensure that the target instance has the same scoped application installed to avoid any issues.

22. Scenario: You need to ensure that an Update Set includes changes made to a custom table. How would you achieve this?

I would ensure that the custom table is included in the Update Set by verifying that the changes made to the table are captured in the Customer Update records. If the changes are not automatically captured, I would manually add the custom table to the Update Set by creating a new Customer Update record for the table. This ensures that all changes to the custom table are included in the Update Set.