ServiceNow engineers have identified a potential data loss that involves the hr_case and hr_task tables during the upgrade to Fuji or later from a prior family release version. The problem is introduced by the workaround provided in PRB629882 / KB0549556. The workaround on the previous issue fails to take into account a scenario where the hr_task or hr_case table is created as Table per Class prior to the upgrade. As a result, when the table is altered during the upgrade, a table conversion takes place that results in data loss.

See the Steps to Reproduce section for a description of the workflow necessary to produce this outcome as well as ways to determine whether your instance is likely to be at risk for this problem during upgrade.

Steps to Reproduce

This section describes the workflow necessary to produce this outcome and ways to identify whether your instance is at risk for this problem during upgrade.

Workflow Necessary to Produce This Outcome

  1. Start with an instance that meets the following criteria:

    • The instance is configured with a Eureka family release.
    • The instance has over one million records in the task table but fewer than 99 million.
    • The value for the glide.db.hierarchy_large_root.task property is the default value (1 million).
  2. Activate the Human Resources plugin.

    This action creates the hr_case and hr_task tables, extending them from the task table.

    The tables are creating using Table per Class because the task table has more rows than the default large root value.

  3. After using the instance for some time, data will be added to the hr_case or hr_task tables.

  4. Implement the workaround described in PRB629882 / KB0549556, setting the glide.db.hierarchy_large_root.task property to 99 million.

  5. Upgrade the instance to a Fuji release or later.

    The following actions occur:

    • During the upgrade, the Human Resources module is updated, including the creation of the sm_order table, which is created as a child of the task table.
    • While creating the table, a check is made against the large root value.  Because the task table has fewer records than the large root value, the sm_order table is created as Table per Hierarchy.
    • As the upgrade continues, the hr_case and hr_task tables are re-parented to the sm_order table.
    • When the tables are reparented, the large root value is tested against the size of the task table and found to be less than the threshold, so hr_case and hr_task are converted to Table per Hierarchy.
    • During the conversion, the data from the child hr_case/hr_task tables is lost due to a defect

Determining Whether Your Instance Might Be at Risk

The team at ServiceNow has been unable to reliably reproduce the issue.  However, we have identified that the following conditions must be true in order to be at risk for this problem during upgrade:

  1. The value for glide.db.hierarchy_large_root.task is greater than the number of rows in the task table
  2. The Extension model for the hr_case or hr_task table is set to Table per class.

If the instance is at risk, data will be lost during the upgrade.  To determine this risk programmatically, execute the following script via the Scripts - Background interface and look for the value returned for at_risk.

(function() {

    var results = {
        at_risk: false,
        task_rows: undefined,
        plugin: undefined,
        large_root: undefined,
        hr_case: undefined,
        hr_task: undefined
    var TPC = 'Table per class';
    var TPH = 'Table per hierarchy';

    function getExtensionModel(table)
        var hr = new GlideRecord(table);
        if (hr.isValid()) {
            var db = GlideRecord('sys_db_object');
                    return getExtensionModel(db.super_class.name);
                    return db.extension_model.getDisplayValue();

    // If the plugin is active, run our tests
    var p = new GlideRecord('hr_case');
    if (p.isValid()) {
        results.plugin = 'active';

        // Get the glide setting (default is 1 million)
        results.large_root = gs.getProperty('glide.db.hierarchy_large_root.task', 1000000);

        // Determine table hierarchy models
        results.hr_case = getExtensionModel('hr_case');
        results.hr_task = getExtensionModel('hr_task');

        // Table size?
        var tsk = new GlideRecord('task');
        results.task_rows = tsk.getRowCount();

        // Determine risk
        if ( results.task_rows < results.large_root && (results.hr_case == TPC || results.hr_task == TPC) )
            results.at_risk = true;

    } else {
       results.plugin = 'inactive';

    // All done
    gs.print(new JSON().encode(results));




If your instance is at risk during an upgrade, please reach out to the ServiceNow Technical Support team.  Once the size of the tables and the table configuration is understood, the correct value for glide.db.hierarchy_large_root.task will be determined. With this set correctly, risk during the upgrade will be mitigated.



Related Problem: PRB662748

Seen In

Eureka Patch 10
Eureka Patch 11 Hot Fix 2
Eureka Patch 13
Fuji Patch 11

Fixed In

Geneva Patch 7

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2016-08-04 06:50:48