Translate sys_id to DisplayValue from template Standard Change Task fields

[lonesoac01]

Hello all,

    I have built the functionality that shows the comparison between a Standard Change Template Task record and the previously approved Standard Change Template Task record.  Here is what the data looks like:

{
"ok": true,
"proposed": {
"taskSysId": "7437e89b3b7dfa1014266ea9e5e45a7f",
"taskName": "44444",
"kv": {
"u_change_task_type": "Implementation",
"u_pvault": "false",
"assignment_group": "019ad92ec7230010393d265c95c260dd",
"cmdb_ci": "8fb4a0871b034918a89e1f49b04bcb69",
"short_description": "fkjfkjfi3j3",
"description": "fire engine!!!fire engine!!!fire engine!!!fire engine!!!fire engine!!!fire engine!!!",
"active": "true"
}
},
"approved": {
"taskSysId": "76c4601b3b7dfa1014266ea9e5e45a5f",
"taskName": "44444",
"kv": {
"u_change_task_type": "Pre-implementation",
"u_pvault": "false",
"assignment_group": "019ad92ec7230010393d265c95c260dd",
"cmdb_ci": "8fb4a0871b034918a89e1f49b04bcb69",
"short_description": "fkjfkjfi3j3",
"description": "erge3ery"
}
},
"trace": {
"pending_approval": {
"std_change_proposal_task": {
"sys_id": "7437e89b3b7dfa1014266ea9e5e45a7f",
"name": "44444"
},
"std_change_proposal": {
"sys_id": "8e17689b3b7dfa1014266ea9e5e45a79",
"number": "STDCHG0005057"
}
},
"approved": {
"std_change_record_producer": {
"sys_id": "6d3734ea3b153e5014266ea9e5e45a91",
"name": "4398gfj983"
},
"std_change_producer_version": {
"sys_id": "b3e6a49b3b7dfa1014266ea9e5e45aa8",
"name": "4398gfj983 - 2"
},
"std_change_proposal": {
"sys_id": "0243d85b3bf9fa1014266ea9e5e45ae6",
"number": "STDCHG0005056"
}
}
}
}

The only thing that I am having an issue with is resolving/converting the sys_id values in the kv object to their DisplayNames.  These values come from the template field in the std_change_proposal_task table.  Anyone know of a solution of how to make these values readable to the average person?

[Its_Azar]

Hi there @lonesoac01 

template field values are stored as raw values (sys_id / true-false), not display values

In script do something like this:

• Get the target table record (std_change_proposal_task)

• For each field in kv, use:

  • gr.getDisplayValue(fieldName) for reference/choice fields

  • gr.getElement(fieldName).getDisplayValue() if you already have the record loaded

logic should be this : 

• Load the task record by sys_id

• Loop through kv

• Replace sys_id values with gr.getDisplayValue(fieldName)

This can help you convert template sys_ids  into readable values. Templates themselves do not store display names.

[Matthew_13]

Hello my Friend!

 You’re running into this because the template stores raw values, not display values; so for reference fields you’ll always get sys_ids back. Nothing is wrong with your data; it’s just how standard change templates work.

What I’ve done in similar implementations is resolve the values at comparison time, based on the field type.

How to approach it (practical and safe)

1. Figure out what each field actually is

   • Look up the field in the dictionary for the target table (usually change_task)

   • That tells you whether it’s a reference, choice, boolean, etc.

2. Only translate when it makes sense

   • Reference fields → look up the record and grab getDisplayValue()

   • Choice fields → convert stored value to label

   • Booleans → true/false → Yes/No

   • Everything else → leave as-is

This keeps your comparison logic clean and avoids hard-coding field names.

The two big ones in your example

In your JSON:

• assignment_group → resolve against sys_user_group

• cmdb_ci → resolve against cmdb_ci

Once those two are converted, the output becomes readable enough for reviewers.

Why this works well

• You don’t mutate the stored data

• You don’t break future template versions

• It scales when new fields are added to the template

Think of it as a presentation layer problem, not a data problem.

If you want to go one step further, a nice pattern is to return:

"assignment_group": {
  "value": "019ad92ec7230010393d265c95c260dd",
  "display": "Network Operations"
}

That way you keep both the raw value for logic and the display value for humans.

@lonesoac01 - Please mark as Accepted Solution and Thumbs Up if you found Helpful!!

[lonesoac01]

I am having an issue with this part:

   "Look up the field in the dictionary for the target table (usually change_task)"

The change_task table is extended from the task table and I am not sure how to only find the fields that are either on the task or change_task table in the sys_dictionary table.

[Matthew_13]

The sys_dictionary table doesnt store inheritance in one combined row. It only records table where field was originally created. Since change_task extends task the fields you can use on a change task come from two places:

• anything created on the task table is automatically available to change_task because of inheritance, and

• anything created directly on change_task is available only there.

Basically to figure out which fields belong to either of those you just need to look for dictionary records with:

• Table = task
  or

• Table = change_task

Those two together are the real field list for a change task record. There isnt a filter like show inherited fields only so the method is simply to check both tables.

If a field isnt found under change_task but it exists under task that means it’s inherited and still valid for your use.

Let me know field name you’re trying to check and I can help you write the exact filter or background query if needed.

@lonesoac01 - Please mark as Accepted Solution and Thumbs Up if you found Helpful!!