Hi @SumanthK7729163 

Could you please try to replace this code in BR and try like this .

From :

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

To:

var test = new x_custom_scope.CustomScriptInclude();
var variableJSON = test.getVariableJSON(current.request_item.toString());  //the way you did it in background script

I tried this way as well but during the creation of payload this is getting impacted during the ccreation json format an html tags will come here

Hi Sumanth,

This is a classic hurdle when generating integration payloads with Reference or Look Up Select Box variables. Because these variable types inherently store the sys_id as their underlying value in the database, server-side scripts will pull that sys_id by default unless explicitly instructed otherwise.

A few things to check in your implementation:

• Display Value Extraction: Inside your getVariableJSON Script Include, ensure you are utilizing .getDisplayValue() rather than just grabbing the value. For example: gr.variables.your_variable_name.getDisplayValue();.

• Instantiation Differences: I noticed a slight syntax discrepancy between your snippets. In the background script, you instantiate the Script Include with new x_custom_scope.CustomScriptInclude(). In the Business Rule, you are calling it statically via CustomScriptInclude.getVariableJSON(...). Ensure your Script Include is properly structured to handle static calls if you aren't instantiating it, and double-check your application scopes.

• Variable Context: Sometimes Business Rules (especially if running asynchronously) handle the current.variables object differently than a GlideRecord query in a background script.

Updating your Script Include to explicitly map display values for lookup variables should resolve the payload discrepancy.

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.

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.