Sharing Extended Tables with Datasets

Datasets provide a reliable mechanism for periodically exporting data from ServiceNow and transferring it to another system. By default, a Dataset operates against a single table. In many real-world integrations, that table may be part of a table hierarchy where multiple child tables extend a common parent.

CMDB is a prime example of this pattern (for example, tables extending cmdb_ci), but the same considerations apply to any extended table structure that customers may want to integrate, not just CMDB.

This document explains the minor scripting changes required to support this.

---

Exporting Extended Tables

Background

When exporting records using a Dataset, Unifi uses the Source to Stage script on the Process message associated with the Dataset (for example, Process_cmdb_ci) to extract data from the source record.

By default:

• The Dataset specifies a table.

• ServiceNow queries that table when building the export.

• The source variable references a record returned from that table.

If the table specified on the Dataset is a parent table, ServiceNow returns only fields defined on that parent table. Fields defined exclusively on child tables are not visible in this context.

This is standard ServiceNow behaviour, and additional logic is required to ensure child-specific fields are accessible.

Approach

To export extended table data correctly, the export must operate on the child record rather than the parent record. This is achieved by resolving the child record dynamically using the parent record’s sys_class_name.

Configuration Steps

1. Open the Dataset Process message used for exporting.

2. Locate the Source to Stage script.

3. At the top of the script, above any auto-generated code, add the following self-executing function:

(function () {
  var gr = new GlideRecord(source.sys_class_name);
  if (gr.get(source.sys_id)) {
    source = gr;
  } else {
    throw "Unable to access " + source.sys_class_name + ':' + source.sys_id;
  }
})();

How This Works

• source.sys_class_name identifies the child table for the record being exported.

• A new GlideRecord is created for that child table and retrieved directly by sys_id.

• If the child record is found, the source variable is replaced.

• The remainder of the Source to Stage script executes against the correct record and has access to all child-specific fields as required.

Performance Considerations

This approach adds one additional GlideRecord.get() call per exported row. Because the lookup is performed directly by sys_id, it should not have a meaningful impact on performance.

---

Importing Extended Tables

Background

When importing records using a Dataset:

• The Stage to Target script on the Process message associated with the Dataset is copied into a Transform Map during the Integration build process. (One Transform Map per Dataset.)

• The Import Set uses this Transform Map during the import process to set required values on the target record.

By default, the Import Set inserts or updates records using the table defined on the Transform Map. That table is controlled by the Dataset table.

In extended table scenarios, this means:

• Parent-level fields should be updated correctly.

• Child-specific fields are never updated, because they do not exist on the parent table.

ServiceNow does not allow dynamic target setting so another approach is required.

Approach

To import into extended tables correctly, the import process must work around ServiceNow’s default Import Set behaviour. The default insert and update logic must be suppressed and replaced with explicit logic that targets the resolved child table.

Configuration Steps

Modify the Stage to Target Script (Top of Script)

At the top of the Stage to Target script, above any auto-generated code, add the following:

// Optional: reset logging to prevent confusion if you reprocess imports
source.sys_import_state_comment = '';
source.sys_row_error = '';

// Tell the import set not to insert/update since we're doing it manually.
// Side effect: all import rows will show as "Ignored".
// We use the import row comment to track inserts/updates instead.
ignore = true;

// Backup ServiceNow's original import target
var import_target = target;

// Take control of the import target so we point to the correct child table
target = new GlideRecord(source.u_sys_class_name);

if (!import_target.isValidRecord()) {
  target.newRecord();
} else if (!target.get(import_target.sys_id)) {
  log.error('Could not get record ' + import_target.getTableName() + ':' + import_target.sys_id);
}

Modify the Stage to Target Script (Bottom of Script)

At the bottom of the Stage to Target script, below any auto-generated code, add the following:

// Since we've taken control of `target` and told ServiceNow to ignore
// this row, we must manually perform the insert/update.
if (!target.changes()) {
	source.sys_import_state_comment = 'No changes. ';
} else if (target.isValidRecord()) {
	source.sys_import_state_comment = target.update() ? 'Updated! ' : 'Update failed! ';
} else {
	source.sys_import_state_comment = target.insert() ? 'Inserted! ' : 'Insert failed! ';
	// Point the import set row to the correct record
	import_target.sys_id = target.sys_id;
}

How This Works

• ServiceNow’s default Import Set behaviour is suppressed using ignore = true.

• The real table name is provided by the import set row data (for example u_sys_class_name).

• A new GlideRecord is created pointing to the child table.

• The script manually inserts or updates the child record.

• The import row comment is used to indicate whether Unifi inserted or updated the record.

---

Additional Notes

Unifi Fields and Extended Tables

Fields and Field Maps are designed to simplify and reuse common mapping logic across Messages. In a typical configuration, Fields reference the same table as the Message. When working with extended tables, Fields can also reference child tables in the hierarchy.

During export and import processing, not all configured Fields will necessarily exist on every resolved record. In these cases, it may be desirable for mappings to be applied conditionally.

This can be handled by explicitly checking for field existence at runtime using GlideRecord.isValidField(field_name):

if (target.isValidField(field_name)) {
  // process field
}

This allows a single Dataset and field configuration to operate across multiple child tables without requiring table-specific logic.