When Catalog Items are modified, a Developer's intention is often to remove or replace existing variables to accommodate new requirements.
What may be unexpected by developers, is when a Catalog Variable is deleted from the form, not only is the variable visibly removed from the form, all of the previously instantiated instances of that variable and all data ever associated with that variable are also deleted.
This causes an otherwise straight-forward development effort, to result in significant historical data loss across the service catalog.
Note: Documentation on Service Catalog Variables can be reviewed in the ServiceNow documentation at:
The data deletion is often noticed by users who are no longer able to see variables and/or questions on their existing Requested Items (RITMs) or Catalog Tasks - it usually goes unnoticed until the deletion is promoted to the production environment.
Consider the following recommendations to avoid deleting historical data when Service Catalog Variables are modified.
Instead of deleting variables from forms, uncheck the "Active" flag, to make the variable inactive. When inactive, the variable is no longer visible to catalog users, AND all the historical data remains unmodified in the database.
Preparing developers and administrators to think in terms of toggling active/inactive instead of deleting data will help to avoid catastrophic deletion events across the platform. It is difficult to anticipate all the ways data might be connected (and therefore deleted), but it is easy to uncheck the active flag (and recheck if needed) to remove obsolete items from user's view.
Thinking in terms of active/inactive is especially important for anyone who has access to writing fix scripts or ad-hoc scripts (using sys.scripts.do), where the UI is not available to seize the user's attention with warnings.
Note: Generally speaking, the best policy is that data should never be deleted from the platform, whether it is through the UI or through a script. Use the Active Flag.
In the ServiceNow platform, in many cases, deleting a record also deletes all referencing records - this is a "cascade delete". For example, when a Configuration Item record is deleted, all tasks referencing that CI are also deleted.
To help a user understand that a cascade delete is going to be executed, the following Warning! message is displayed before the user is allowed to proceed with the Delete ---
When a message like this is displayed, more than just the current record will be deleted. In this case, 3 rows from the Question Choice table will also be deleted. All tables where data will be deleted are listed in this message.
Administrators and Developers should be able to recognize and understand the implications of a deletion that displays this message. If the message reports 2,523 Question Choices will be deleted, the user should be trained to stop and consider the ramifications before deleting this record and all records referencing this item.
Developers should keep in mind, the deletion activity will be added to the update set and will be promoted to production where it will delete all records that match the deletion criteria.
Being aware of these messages will help avert accidental data deletions.
The cascade deletion feature described above is governed by a setting on each reference field in System Definition > Dictionary. The value in the field Reference cascade rule instructs the Cascade Delete facility how to handle the record that references the item to be deleted.
When configuring Cascade Delete Rules, you are not configuring the table holding the record being deleted: Instead, you are configuring how to handle records that reference (i.e. point to) the record being deleted. As a result, when you search for the cascade delete rules for "User", you do not search for table = sys_user in the dictionary … You search instead for Reference = User.
For example, Navigate to System Definition > Dictionary, Click the cog wheel to configure the fields shown in the list and choose: Reference and Reference Cascade Rule so that they are displayed in the list.
Search for Reference = Question. The resulting list shows all fields that reference the Question table, and the Reference cascade rule column shows what will happen to records that are referencing the record to be deleted.
There are a few choices for the reference cascade rule setting, but for this article, the focus is on Restrict.
When the reference cascade rule is set to Restrict, the platform does not allow the original item to be deleted as long as there are records from the reference column marked Restrict that match the item to be deleted.
In this example, the reference cascade rule is set to Restrict for question_answer.question and question_choice.question, when the Delete button was pressed for a question --
The record was not deleted because there are records in the Question Choice and Question Answer tables which point to the question "Is this service category for a Department or a Group?"
Note: Documentation on Cascade Delete Rules can be found in the standard ServiceNow documentation at: https://docs.servicenow.com/csh?topicname=t_CascadeDeleteRules.html&version=latest
In summary, if you delete Catalog Variables from forms during a development cycle, you will also delete all the user data historically collected with the variable. Being aware of the way the platform handles deleting data can help avoid unintended data loss, such as catalog variable data.
Follow these guidelines to avoid unintended deletes: