OOTB Bug in SOW Incident to Change Flow: Reference Field company Added to URL Query as Display Value

[Rockie]

Hello ServiceNow Team,

We found a possible OOTB bug in Service Operations Workspace after upgrading to the Australia release.

The version of SOW is 9.2.0

When creating a Change Request from an Incident in SOW, the action opens a URL like this:

/now/sow/record/incident/<incident_sys_id>/sub/record/change_request/-1/params/query/...

In the generated query, the company reference field is added as a display value:

company=*************** Co., Ltd.

However, since company is a reference field, the query should use the sys_id instead:

company=<company_sys_id>

When the URL contains the display value, the new Change Request page fails to initialize and SOW shows:

Security constraints prevent access to requested page

We confirmed that manually replacing the company display value with the company sys_id in the URL allows the page to open correctly, the Change Request to be created, and the Incident to be linked successfully.

Root Cause what I guess

The issue appears to come from the following OOTB Script Include:

SOWChangeUtilsSNC

Specifically, this method:

getValidatedChangeQueryFromTask: function(table, sysId)

The method builds the encoded query from source task fields. For non-choice fields, it uses:

sourceGr.getDisplayValue(field)

Example:

queryParts.push(field + '=' + GlideStringUtil.escapeQueryTermSeparator(sourceGr.getDisplayValue(field)));

This is problematic for reference fields such as:

 - company
 - cmdb_ci

because reference fields should be passed using their stored value, meaning sys_id, not display value.

The issue is triggered through the following OOTB UX Data Broker Transform:

Get Validated Task Fields Query

which calls:

new SOWChangeUtils().getValidatedChangeQueryFromTask(table, sysId)

Recommended Fix

Please update the OOTB logic so that reference-like fields use getValue() instead of getDisplayValue().

Suggested logic:

var element = sourceGr.getElement(field);
var ed = element ? element.getED() : null;
var internalType = ed ? ed.getInternalType() : '';

if (this._fieldHasChoices(targetTable, field)) {
    if (!this._isValidChoice(targetTable, field, value))
        continue;

    queryParts.push(field + '=' + value);
} else if (internalType === 'reference' || internalType === 'domain_id' || internalType === 'glide_list') {
    queryParts.push(field + '=' + value);
} else {
    queryParts.push(field + '=' + GlideStringUtil.escapeQueryTermSeparator(sourceGr.getDisplayValue(field)));
}

Workaround

As a temporary workaround, we overrode the method in:

SOWChangeUtils

instead of modifying:

SOWChangeUtilsSNC

After applying this workaround, the generated URL uses:

company=<company_sys_id>

and the Incident to Change creation flow works correctly again in Service Operations Workspace.

Could ServiceNow please review and fix this OOTB logic?

Thank you.