Notifications

197 views

Overview


It has been found that there has been a change in the values stored within the sys_journal_field table with the Jakarta version and above.  The change will only really be noticed for customers upgrading from Istanbul (or earlier) versions of the ServiceNow platform to the Jakarta or newer versions of the platform.

This particular change is relating to the value as stored in the name field of this table.

What has Changed


Starting with the Jakarta release of the product, in tables that use the TPH (Table per Hierarchy) storage model, particularly those tables in the task hierarchy, automated updates to a record will populate the name field of the sys_journal_field table with the specific name of the extended table.

In the Istanbul version and previous versions which supported the TPH model, the base table would be stored in the name field of the sys_journal_field table.  Thus, for the task table hierarchy, the name field would contain the value "task" in the Istanbul and previous versions.  However, in the Jakarta and later versions, this value would contain the actual value of the child table being manipulated (i.e. incident).

This could be noticed in a few different areas, however the area in which this issue is most commonly reported is in the area of a Business Rule.  The issue usually is reported as a Business Rule that has suddenly stopped triggering after a recent upgrade from the Istanbul (or earlier) version of the product to a newer version, such as Jakarta or Kingston. 

Example


As a simple example, a customer may have previously had a Business Rule associated to the Incident table that included a condition such as the following:

current.name == "task"

However, after upgrading they may have noticed that this Business Rule has suddenly failed to trigger as expected.  The cause of this Business Rule failing to trigger is because any further automated updates or inserts of records in the sys_journal_Field would update the value of the name field with the value "incident" whereas previously it would have updated with the value "task".

The following image shows a record inserted into the sys_journal_field table as a result of an update to the Work Notes field on an Incident record as it might appear in the Istanbul version of ServiceNow:

 Insert into the sys_journal_Field table in the Istanbul version of ServiceNow

Notice the Name field shows as "task" despite the fact that the actual record updated was of type task.

The following screenshot is a similar update performed in a Kingston version of ServiceNow.

 Insert into the sys_journal_Field table in the Kingston version of ServiceNow

Notice that in this instance, the Name field shows as "incident" which is the actual table name in which the update was performed.

Work Around


There are a number of methods a customer may be able to work-around the issue.  Each Business Rule would need to be independently analyzed to determine the best method to resolve.  However, in the example given above, suppose a customer had a Business Rule that had previously included the criteria current.name == "task".  in order to resolve this, one potentially straightforward method would be to modify this criteria to instead contain the exact name of the child table on which the Business Rule is intended to act upon (i.e. it might be changed to current.name == "incident".  The following screenshots show how this criteria might have appeared before and after performing this change to the Business Rule.

Business Rule condition in the Istanbul release

 

Business Rule condition in the Jakarta or later version of ServiceNow

As always, ensure to thoroughly test all changes to Business rules in a sub-production environment before promoting the rules or other objects to an active, production instance.

Article Information

Last Updated:2018-10-16 10:05:38
Published:2018-10-08