SOW form view mandatory field and internal notes query

[sharsha]

1. The required field should be made red asterisks, can we make them red colored? Please refer attached.
2. Internal Notes section is yellow in color in ITIL view as per screenshot attached.
Can we make them same colored style in SOW view. Thanks!
Please advise!

[Suryansh Verma · Accepted solution]

@sharsha 

g_form.setSectionDisplay() is supported in Service Operations Workspace, so the API itself should work.

I can see two potential issues in your implementation.

1. Remove the URL check first.
Your script checks top.location.href for now/sow. I would not use the URL to determine whether the form is running in SOW, because current Workspace record routes do not always contain that value, and access to top/window can also be affected by Client Script isolation.

Configure the Client Script for the SOW form view instead and test:

function onLoad() {
    console.log(JSON.stringify(g_form.getSectionNames()));
    g_form.setSectionDisplay('assignment', false);
}

getSectionNames() will show the exact section identifier available on that form, so please confirm that assignment is actually returned.

2. Check mandatory fields inside the Assignment section.
In your New Incident screenshot, Assignment group appears to be mandatory and empty. ServiceNow will not hide a section containing an empty mandatory field, otherwise the user would have no way to populate the mandatory value.

If Assignment Group is populated automatically by assignment logic and does not need to be entered by the agent, you would need to remove the client-side mandatory requirement before hiding the section:

function onLoad() {
    g_form.setMandatory('assignment_group', false);
    g_form.setMandatory('assigned_to', false);
    g_form.setSectionDisplay('assignment', false);
}

Only do this if the field is populated/validated elsewhere.

Also note that SOW uses two different form views:

Service Operations Workspace
→ existing Incident Details form

Service Operations Workspace New Record
→ Create New Incident form

If the Assignment section should always be hidden rather than conditionally hidden, I would not use a Client Script. Configure both of those views under Configure → Form Layout and remove the Assignment fields/section from the respective SOW views. That is the cleaner OOTB approach.

If my response helped, please mark it as correct and close the thread, this helps future readers find the solution faster!!!

[NehaG8791370651]

Hi Sharsha,

These types of UI requests are incredibly common when migrating users from the classic UI16 to the Service Operations Workspace (SOW). However, because SOW is built on the Next Experience (Seismic) framework, the technical approach to UI configuration is entirely different.

Here is the technical breakdown for both of your requirements:

• Requirement 1: Red Asterisks for Mandatory Fields. Unlike UI16, you cannot inject simple CSS or DOM manipulation to change this. The Next Experience UI utilizes a unified design system (Polaris). While you can technically modify UX Theme properties (via JSON) to alter semantic colors globally, modifying the specific mandatory indicator to red is highly discouraged. It requires deep theme overrides that can break UI consistency across other Workspace components.

• Requirement 2: Yellow Background for Internal Notes. In the classic ITIL view, you likely used Field Styles (sys_ui_style) to make the background yellow. The Next Experience Activity Stream component does not inherit these legacy background-color field styles for the journal input box. Instead, SOW handles this natively by separating "Work notes" (Internal) and "Additional comments" (Customer visible) into distinct tabs, and it applies a subtle yellow visual indicator (like a colored bar or icon) to the internal notes in the activity stream.

The Technical Recommendation: Trying to force UI Builder components to mimic legacy UI16 behaviors requires building custom web components. This introduces massive technical debt for purely cosmetic changes. I strongly advise leveraging the out-of-the-box (OOB) Next Experience visual indicators instead!

[Tanushri]

Hi Sharsha,

Thank you for bringing this up! From a business and deployment strategy perspective, questions like this are rarely about the technology itself—they are almost always about Organizational Change Management (OCM).

When service desk agents ask for red asterisks or bright yellow boxes, it is because they have spent years relying on those specific visual cues to do their jobs quickly. Moving to Service Operations Workspace (SOW) disrupts that muscle memory, so they naturally request that you make the new system look like the old one to reduce their learning curve.

While it is tempting to try and fulfill these cosmetic requests to appease the users, doing so actually harms the overall ROI of your Workspace implementation.

• Wasted Cycles: Engineering hours spent hacking the UI to change colors are hours not spent building automations that actually reduce ticket resolution times.

• Delayed Adoption: Shielding users from the new interface delays true adoption. SOW has excellent, modern visual indicators for internal notes (like separated tabs and activity stream markers).

The most strategic approach here is to lean into training. Guide your agents to understand how the Next Experience surfaces mandatory fields and internal notes differently. Addressing the human element of this transition will yield much better long-term results than accumulating technical debt for cosmetic tweaks!

[Suryansh Verma]

@sharsha 

These are actually two separate behaviours in SOW.

1. Mandatory asterisk

In Service Operations Workspace the required indicator is state-based. An unpopulated/invalid mandatory field uses the required/error styling, while once the mandatory field has a valid value the indicator returns to the neutral grey/black state. So I would not recommend overriding the SOW theme/CSS just to keep every mandatory asterisk permanently red.

If an empty mandatory field never shows the red/error state even after attempting to save, that would be a separate issue to troubleshoot.

2. Yellow Internal Notes / Work Notes

The classic UI16 yellow background on the actual journal input field is not inherited by SOW in the same way.

If the requirement is to distinguish Work Notes entries in the Activity Stream, there is a supported Workspace configuration:

System Definition → Dictionary
Task [task] → work_notes → Attributes

Workspace activity stream background = yellow
Workspace activity stream apply variant = BORDER_AND_BACKGROUND

Workspace activity stream background sets the Work Notes tile variant to yellow. BORDER_AND_BACKGROUND makes the color appear on both the border and background rather than only the border.

This affects the posted Activity Stream entries, not the editable Work Notes textarea itself.

If the exact requirement is to make the Compose/Internal Notes input box itself yellow before posting, I am not aware of an OOTB field-level property in SOW that reproduces the UI16 yellow textarea. The Compose editor is a Next Experience/UI Builder component, so achieving that exact UI16 appearance would require customization of the component/theme, which I would avoid for a cosmetic requirement.

So I would use the supported Activity Stream color attributes for visual differentiation and retain the standard SOW styling for the Compose input.

If my response helped, please mark it as correct and close the thread, this helps future readers find the solution faster!!!

[sharsha]

Thanks,
Can you please let me know how can we hide assignment section in SOW view?

I've created below Onload client script to hide 'Assignment' section in the "Incident Management for Service Operations Workspace" scope and it didn't work for me. Please advise. Thanks!

I still see 'Assignment' section in SOW record view and SOW new record view. Please check and advise.

[Suryansh Verma · Accepted solution]

@sharsha 

g_form.setSectionDisplay() is supported in Service Operations Workspace, so the API itself should work.

I can see two potential issues in your implementation.

1. Remove the URL check first.
Your script checks top.location.href for now/sow. I would not use the URL to determine whether the form is running in SOW, because current Workspace record routes do not always contain that value, and access to top/window can also be affected by Client Script isolation.

Configure the Client Script for the SOW form view instead and test:

function onLoad() {
    console.log(JSON.stringify(g_form.getSectionNames()));
    g_form.setSectionDisplay('assignment', false);
}

getSectionNames() will show the exact section identifier available on that form, so please confirm that assignment is actually returned.

2. Check mandatory fields inside the Assignment section.
In your New Incident screenshot, Assignment group appears to be mandatory and empty. ServiceNow will not hide a section containing an empty mandatory field, otherwise the user would have no way to populate the mandatory value.

If Assignment Group is populated automatically by assignment logic and does not need to be entered by the agent, you would need to remove the client-side mandatory requirement before hiding the section:

function onLoad() {
    g_form.setMandatory('assignment_group', false);
    g_form.setMandatory('assigned_to', false);
    g_form.setSectionDisplay('assignment', false);
}

Only do this if the field is populated/validated elsewhere.

Also note that SOW uses two different form views:

Service Operations Workspace
→ existing Incident Details form

Service Operations Workspace New Record
→ Create New Incident form

If the Assignment section should always be hidden rather than conditionally hidden, I would not use a Client Script. Configure both of those views under Configure → Form Layout and remove the Assignment fields/section from the respective SOW views. That is the cleaner OOTB approach.

If my response helped, please mark it as correct and close the thread, this helps future readers find the solution faster!!!