As is said When i run in background script i am able to get GetDisplay Value from the below line

jsonVariables.display_value = question.getDisplayValue();

But when actual scipt will run when created via sc_task i am getting the sys_id

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.