Incident Form - CAtegory-SubCategory field value

[MThomas1]

We have Category-Sub category field on Incident form and Change form.

Incident Form - Category-SubCategory field value need to be updated with new choices and existing choices need Inactivation.

Questions:

1. How can we report on the Inactive sub category field value in future?

2.There are some state= Open/pending/Inprogress incidents with one of the value within the inactivation list, what is the best practice to handle these incidents?

3. We would like to use a UI policy to make sub category field  "Required" based on a parent value .  Since we have this fields on Change form ,  how/will this UI policy affect Change form?

Thank you and appreciate input from the community.

[RaghavSh · Accepted solution]

1. Even if you deactivate the choice , you can still do show matching on "category field" on incident. Or in the URL you can built "sysparm_query=category='deactivated choice' in URL.

2. All open incidents should eb assigned to valid active choice.

3. Cat/Subcat fields are not on task form OOB, they are on incident form individually so same fields cannot be on change form. So in short UI policy will not affect change form.

Please mark the answer correct/helpful accordingly.

[RaghavSh · Accepted solution]

1. Even if you deactivate the choice , you can still do show matching on "category field" on incident. Or in the URL you can built "sysparm_query=category='deactivated choice' in URL.

2. All open incidents should eb assigned to valid active choice.

3. Cat/Subcat fields are not on task form OOB, they are on incident form individually so same fields cannot be on change form. So in short UI policy will not affect change form.

Please mark the answer correct/helpful accordingly.

[Rafael Batistot · Accepted solution]

Hi @MThomas1 

• Reporting on inactive subcategories → Even if you inactivate a choice, existing records keep their stored value. You can still report on them in the future because the raw value remains in the database.

• Handling open incidents with soon-to-be inactive values → Best practice is to update those active records to a valid new value (via script or data migration) before inactivation, so users don’t get stuck with obsolete data.

• UI Policy impact → UI Policies are scoped to a specific table. If you create it on Incident table, it won’t affect the Change form, even if the field name looks the same. You would need a separate UI Policy for Change if required.

[MThomas1]

Thank you for both input.