Type field displays Normal for Emergency and Standard Changes before save in SOW

[krishnac6401489]

Hi ,

We are facing an issue in Service Operations Workspace (SOW) while creating Change Requests.

When creating an Emergency or Standard Change using the respective Change Model, the Type field initially displays as Normal on the new Change Request form.

After saving the record, the Type field is correctly updated to Emergency or Standard based on the selected Change Model.

This issue occurs only in SOW. In the Native UI, the correct Type is displayed before saving.

[Vikram Reddy]

Hello @krishnac6401489,

This is a client script scoping issue, not a Change Management bug. The Type field on change_request isn't driven live by the platform's Change Model logic itself, it's populated on the form by an onChange client script that reacts to chg_model, and separately by server-side logic that runs on save regardless of which UI you're in. That's exactly why the value corrects itself the moment the record is saved, the save path always runs, the live form update doesn't.

Client scripts built for the classic UI don't automatically execute inside Service Operations Workspace. SOW renders through UI Builder using its own view (sow), which is a different execution context than the legacy Desktop or Mobile / Service Portal contexts a client script's UI Type field can be scoped to. If the script that sets Type off chg_model is scoped to Desktop only, or predates workspace support, it simply never fires in SOW, so the field just sits on whatever the default value is, Normal, until save.

Worth checking, in this order:

• Open sys_script_client filtered on table change_request and find the script reacting to chg_model, search the script body for "type" if the name isn't obvious.
• Check its UI Type field. If it's set to Desktop, that's your root cause, change it to All so it also fires in Workspace.
• If the script reads the model's type via g_form.getReference() synchronously, that pattern is unreliable in Workspace, since references resolve asynchronously there, it needs the callback version.
• Check for a UI Policy on change_request scoped the same way, some builds set Type via UI Policy action instead of a client script.
• If none of the above applies, the logic may live in a UI Builder client script or client state parameter tied to the sow view, and it may need to be added there directly rather than re-scoped.

Thank you,
Vikram Karety
Octigo Solutions INC