Look Up select box is not working via integration

SumanthK7729163 · 3 weeks ago

1) In the background script is working fine :

var taskSysId = '5f1f516dc35203d05a76d5fe0501315d';
var grTask = new GlideRecord('sc_task');

if (grTask.get(taskSysId)) {
var ritmSysId = grTask.request_item.toString();
gs.info("Found Parent RITM: " + ritmSysId);

var test = new x_custom_scope.CustomScriptInclude();
var variableJSON = test.getVariableJSON(ritmSysId);

gs.info("Variable JSON Output:\n" + JSON.stringify(variableJSON, null, 4));
} else {
gs.error("Could not find an sc_task record with the provided sys_id: " + taskSysId);
}

2) when i run via Business rules and script includes its getting the Sys_id Instead of script inlcude in the payload generation

...
var variableJSON = CustomScriptInclude.getVariableJSON(current.request_item.toString());
....

var payload = {};
...
payload.variables = variableJSON;
....

// Genericized custom table name
var transactionlogGr = new GlideRecord('x_custom_scope_transaction_log');
transactionlogGr.initialize();

transactionlogGr.payload = JSON.stringify(payload);

.......................

Rafael Batistot · 3 weeks ago

Hi @SumanthK7729163

may you try replace

var variableJSON = vendorIntegrationOutboundUtils.getVariableJSON(current.request_item.toString());

to

var variableJSON = vendorIntegrationOutboundUtils.getVariableJSON(current.getValue('request_item'));

The issue occurs because in scoped Business Rules within ServiceNow, using ⁠current.request_item.toString()⁠ can fail to extract the pure string of the reference ⁠sys_id⁠, passing a ⁠GlideElement⁠ object instead. This causes the ⁠GlideRecord⁠ query in the Script Include to fail or behave inconsistently.

The correct way to retrieve the ⁠sys_id⁠ as a clean string within the Business Rule context is to use ⁠current.getValue('request_item')⁠.

If this response was helpful, please mark it as Helpful and, if applicable, as Correct.
This helps other users find accurate and useful information more easily

View solution in original post

VJ_Srivastava · 3 weeks ago

Hello Sumanth,

From a platform architecture perspective, this behavior makes sense. ServiceNow defaults to passing the sys_id for reference and lookup fields to maintain strict referential integrity across its data model.

However, when building an integration layer, downstream systems almost always require human-readable strings rather than system identifiers. To make your architecture more robust and scalable, I recommend updating your CustomScriptInclude to act as a centralized serialization utility.

You can script it to dynamically inspect the dictionary type of each variable in the requested item. If it detects a reference or lookup type, it should automatically extract and map both the sys_id and the display value into your JSON payload. Abstracting this logic into a universal utility now will prevent your team from having to write custom data transformations for every future integration you build.

NehaG8791370651 · 3 weeks ago

Hi Sumanth,

This is a common "gotcha" when transitioning logic from a background script to a Business Rule. The discrepancy usually happens because the background script queries the database directly, while the Business Rule interacts with the current object in memory during a transaction.

Look Up Select Box and Reference variables inherently store the sys_id at the database level. To fix this, you need to ensure your getVariableJSON function in the Script Include explicitly requests the display value.

Instead of just grabbing the variable's value, make sure you are using .getDisplayValue() on the specific element (e.g., current.variables.your_variable.getDisplayValue()). Also, double-check your Script Include's accessibility and ensure it is properly handling the static call CustomScriptInclude.getVariableJSON() if you aren't instantiating it with new in the Business Rule.