Cascading with reference fields

Reference fields are pretty special in ServiceNow. They let you link two records, letting you associate things such as which room you just checked in to. It represents a relationship that makes sense for your data.

Tip

Almost every reference field uses sys_id values to join records. But you do have the power to specify another field, by populating the Reference key in the advanced settings of the dictionary. This requires careful consideration for it to make sense, though.

Relationships change, though. Wouldn't it be great to create the other side if needed? And clear up broken links when one side goes? At least in ServiceNow, this is possible.

Dynamic creation

What happens if you try to associate with a record that doesn't exist, such as performing a check-in for a guest that has never been to the hotel before? If you type a name into the reference field that doesn't match an existing record, then the red background warns the user that the record won't be saved properly. Indeed, if you try, you will get a message saying Invalid update.

One way to create a record quickly is to use the reference icon and click on the New button in the list in the popup window. You then get a form that you can fill out, which comes with a Save button. But a faster way is to use dynamic creation, which allows you to type the name directly into the reference field. Here's how:

1. In Studio, click on the Check-In table in the Application Explorer, and in the Table Columns list, find Guest and click on it.
2. In the Guest Dictionary Entry form, click on Advanced View under Related Link. Make the following changes in the Reference Specification section and Save.
   • Dynamic creation: <ticked>

   Tip

   Note there is a Dynamic creation script field, but the default functionality works well enough.

3. Now, try going back to the Check-In table, and type in the name of a guest that hasn't been created. Instead of red, it will have a green background. This indicates that the record will be created.
   

By default, the new record will have the display value populated. For a User record, the display value is a field, called Name, that is actually dynamically created from the First name and Last name fields. The scripts for the User table will organize the data in the most appropriate place.

When you turn on dynamic creation, you'll see an area in the dictionary for scripting a more complex scenario. Sometimes, this is helpful, if only to flag that this record was dynamically created. Often, you want to track this happening, since it is very easy to create lots of duplicates with dynamic creation; for example, is it Tom, Thomas, or Tommy?

Deleting records

When you click on the Delete button in a form or a list, the platform removes the record from the database. But what if there is a reference-field value that points to that record? The Check-in table has a reference field that points to the Room table. If we delete a Room record, what happens to the Check-in records?

There are several ways in which ServiceNow can deal with the situation, and you can choose what happens with the dictionary entry of a reference field:

• By default (or when the choice is set to Clear), the platform will empty the reference fields that point to that record. When deleting a Room record, all of the Check-in records that point to it will have the Room field emptied.
• Delete or Cascade: Any record that pointed to the deleted record is also deleted. This means that deleting a room would also delete all the Check-in records that pointed to it! Delete no workflow is an extension of this; with this option, only directly related records will be deleted (it does not cascade).
• Restrict: This option will stop the transaction if there are related records. If there are any records pointing to the deleted record, then the deletion will be aborted. The platform will prevent you from deleting the room. This is the most conservative option, useful for preventing mistakes.

  Tip

  For instance, once a room has been checked in to, you may not want to delete it. You should first contact the customers staying there and let them know that a wrecking ball may come through their walls!

• None: This option will mean that the platform does not alter any related records. Reference fields will stay populated with a sys_id value that points to an invalid record.

The majority of the time, the default option of Clear is the right choice. It does mean, however, that you lose information when deletions occur. So, in general, the best idea is not to delete anything! Users should be deactivated in production systems, not deleted.

Tip

If you accidentally delete something, it may be found by navigating to System Definition > Deleted Records. The platform will even allow you to restore data that has been removed through a cascade delete. This only works for audited tables however. Check out the product documentation for more information: https://docs.servicenow.com/bundle/geneva-servicenow-platform/page/administer/system_logs/concept/c_RestDataRecordsDelAud.html.

This scenario also illustrates why the automatic fields are not reference fields, but instead copy information into the record. The Created By and Updated By fields store the text value of the user who performed the action, so they are not dependent upon the user record itself.