TOKYO+ UPDATE: Catalog builder submissions are automatically packaged into Update Sets for easy deployment to test/prod.

To understand why migrating Catalog items updated with Catalog builder is challenging, we must first understand what happens behind the scenes when an item is updated.

What happens when a Catalog item is checked out?

• All configuration is copied to an inactive copy
  • Variables keep a reference to the published variable
  • All other configuration is copied with no reference to the original
• Published item is read-only

What happens when a Catalog item is submitted?

• The existing item is updated
• The following configuration is deleted on the original item
  • Variable Sets (Question Sets)
  • UI Policies (Dynamic Behaviours)
  • Fulfilment Steps
  • Any other pertinent changes
• Existing variables are updated with any changes
• New variables (Questions) are recreated from the original item
• Checked out item is deleted

So, what exactly is the problem?

• If you want to follow best practices, you will still want to update the item first in DEV then follow your standard development practices.
  • Alas, items will need to be moved to test via Update sets
• Catalog builders typically are not admin users and don’t have access to Update Sets
• All updates for them are saved to the Default Update set
• We don’t want to tell business users to recreate the updates in each environment
• We can’t just copy all the current configurations, as the upstream item will have different sys_id’s for all configurations
  • You’ll end up with duplicates
• For any new variables, the published reference won’t exist
  • This must also be moved to the next environment

So, how do I migrate updates made in Catalog builder?

When an item has finished being updated and all changes have been submitted, a developer must

• In your development environment:
  • Create a new Update Set and set to current
  • Navigate to the published item
  • Add any new variables to Update Set (including question choices)
    • Consider using ‘Add to Update Set’ to help with this
    • If you are not sure if/which is new, add them all to the Update set
  • Check out the item in Catalog Builder
  • If the item does not exist in Test
    • Submit the item in Catalog Builder
    • Complete your Update Update Set
      • In Test/Prod
        • Retrieve Update set
        • Commit Update set to Test/Prod
          • If this is done correctly, there should be no errors
        • Open checked out item in Catalog Builder
        • Submit the item
  • If the item does exist in Test/Prod
    • Complete your Update Set
    • Cancel your check out

The above step will take care of deleting the old configuration and replacing it with the new one, so you don’t have to worry about duplicate configuration creeping in.

Doesn’t this create more work for developers? 

While this issue creates a little more work for ServiceNow Administrators, Catalog builder by business users still frees up their time to work on more valuable tasks and is a net benefit.

As a result of this method, some configurations will have different sys_id’s in each environment. However, as long as you follow good development practices and clone regularly, this should not be a problem.

ServiceNow is aware of this issue and is working to fix it in future releases. In the meantime, you can use the method above to transfer updates and continue using Catalog builder with confidence.