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!!!

[sharsha]

@Ankur Bawiskar attached above, Thanks

[SohamTipnis]

Hi @sharsha,

I don't think this can be accomplished unless there is a lot of customization. You might look into ITIL overview and some onChange clients by doing this for them.

If you find my answer useful, please mark it as Helpful and correct.‌‌😊

Regards,
Soham Tipnis
ServiceNow Developer || Technical Consultant
LinkedIn: www.linkedin.com/in/sohamtipnis10

[arzhost]

I think having the required fields clearly highlighted in red would make the SOW form much easier to understand at a glance. It would also be helpful if the Internal Notes section could follow the same visual style as the ITIL view for consistency.

[sharsha]

@Dr Atul G- LNG 

PFA, There is no option to remove the section there, please advise.

[VJ_Srivastava]

Hello Sharsha,

From an architectural standpoint, this scenario highlights the fundamental shift between the legacy ServiceNow UI and the modern Next Experience framework.

In classic UI16, the platform allowed for heavy, fragmented UI customization (like forcing red asterisks or painting field backgrounds yellow). While flexible, this historically led to massive technical debt, broken forms during version upgrades, and severe performance degradation.

With SOW and the Next Experience, ServiceNow has moved to a strict, component-based design system. The architecture is intentionally locked down to ensure high performance, accessibility compliance, and seamless upgrades.

When your organization migrates to Workspaces, attempting to recreate the exact cosmetic paradigms of the legacy system is an architectural anti-pattern. If you modify the underlying UX Theme JSON to force legacy colors into modern components, you are actively opting out of the scalability and upgrade-safety that the Next Experience provides. I highly recommend advising your stakeholders to adopt the platform's new, standardized visual cues rather than spending engineering cycles trying to make the new system look exactly like the old one.