Changing Custom Fields on existing catalog items affecting open tickets.

Hi JoeyB , first off, great name! This should not be happening when it comes to service catalog requests and would only be happening if these fields are apart of a form and dynamic form rule that gets put in place on the request post submission. I know this post was from 2 months ago so I am wondering if you got this same answer somewhere else or if this is still an open issue for you?

Thanks!

LOL, Hey Joey.  Thanks for the response.  No answer anywhere else on this and still happening.  The fields are custom fields on the ticket form with no dynamic rules applied to them.  Just straight input.

Hmm weird. Let me get with engineering in the next week or two and see if that is expected. I thought and think it should only impact newly created service requests and not even ones in flight. 

Any update on this one? Having inherited our SWSD instance, I was going to go through and clean up custom fields that we're no longer using (somehow, we ended up with over 800...). If it's going to wipe information out of a bunch of old tickets. I probably dont want to do that...

TL;DR - This is due to the way we use our custom forms functionality to populate custom fields in the details tab. This only impacts the fields in the details tab and the fields/inputs in the request inputs are not effected by changes to the catalog item. We see this as something we can fix and are looking at versioning as a possible solution. 

Thanks for bringing this back to the top of my list! I did speak with engineering and this is what we found:

• Custom fields on service catalog items are set in two different places on a request.
  • In the request inputs section which lives under the description field
  • In the details tab
• When you remove a custom field from the service catalog item it removes the field from the details tab across all previously submitted requests. 
  • Note: the data is still stored in the field in the database but this action removes it from the UI
• When you remove a custom field from the service catalog item it DOES NOT remove it from the request inputs section for all previously submitted requests. 

So what does this mean and why is this happening?

1. The previously submitted data is still intact on the request and not gone if you remove the custom field from the catalog item.
2. You can still see the data on the index in columns and filters
   1. This is possible because the columns and filters on the index do not care if the field is visible on the actual form on the incident/request
3. This is happening because of the way we are populating the request inputs to custom fields for things like runbooks, modifying inputs post submission, and our custom form functionality. When a service request is submitted we are applying a "custom form" that includes all the service catalog fields so they show up in the details tab. If the "custom form" aka the service catalog item is modified it is reflected across all places that "custom form" is used. 
   1. I say "custom form" because it is not an actual custom form you can see in Setup - Custom Forms so I dont want anyone reading this to think they did something in the custom form area and caused an issue. Its a background thing we are doing and using the custom form functionality to do it. 

What are product's thoughts on this?

We can do this in a better way and will be working with engineering on how we can best handle this. There have been talks of actual versioning of service catalog items and I personally think that is the best way forward. This will give you all more control of testing catalog items before you publish them, being able to revert back, and be able to make sure previous submissions stay intact. This is a big effort and I am currently seeing how it plays into our roadmap and how we can develop it to not just help in the service catalog area but all areas that should have versioning (solutions, change catalog items, custom forms, etc).