Problem Form (Native UI) - Increase Visibility of HTML Fields (Workaround & Cause Notes)

_Yash24
Tera Guru

3 weeks ago - last edited 3 weeks ago

Hi,

I am investigating a difference between our instance and OOTB behavior for the Problem form in Native UI.

 

The fields Workaround and Cause notes are HTML fields. In OOTB instance, these fields display with a larger editor area by default, making it easy to see whether content has been entered.

 

However, in our instance, the same fields appear with a very small height and require users to click the + icon to expand them before they can easily view the content.

 

What I've already checked:

- The fields are still configured as HTML type.
- No intentional customization has been done on these fields.
- I compared HTML editor-related system properties between our instance and OOTB and did not find any differences.
- The issue is observed only in Native UI.

 

My questions are:

1. What controls the default visible height of HTML fields on a form?
2. Besides HTML editor-related system properties, are there other settings, dictionary attributes, UI macros, or configurations that can affect the initial size of HTML fields?
3. Has anyone encountered a situation where OOTB HTML fields appear expanded in one instance but collapsed in another?
4. Are there specific dictionary attributes or form-level settings I should compare between the two instances?

 

The screenshot below shows the behavior in our instance.

_Yash24_0-1792593876962.png

 

 

Any guidance on where to investigate next would be greatly appreciated.

 

Thanks,

Yash

Preview file
53 KB
0 Helpfuls
  • 587 Views
3 REPLIES 3

Abhishek_W
Giga Guru

3 weeks ago

Hi @_Yash24 ,

Most likely cause: a dictionary attribute or dictionary override on problem.work_around and problem.cause_notes (check for height=, also on the parent task table), or a customized HTML-related UI macro/UI script.

What to compare between the two instances
1) Dictionary entry for problem.work_around and problem.cause_notes: Type, Attributes, and Max length. Also check the same on the parent task table in case of inheritance.
2) Dictionary Overrides (sys_dictionary_override) filtered on table = problem.
3) UI Macros (sys_ui_macro) and UI Scripts with “html” in the name: check Updated and Updated by columns.
4) Customization/Skipped changes (sys_upgrade_history, sys_update_xml for those artifacts, and “Skipped Changes” under System Update Sets → Upgrade History).
5) Client Scripts and UI Policies on problem referencing these two fields.
6) Form design (Form Layout and Form Styles) for the Problem form view you are using.
7) Release version and installed plugins.

If you find this helpfull , Accept ✔️ the solution  and mark Helpful 👍.


Regards,

Abhishek

0 Helpfuls

BhavaniYamsani
Tera Expert

3 weeks ago

Hi @_Yash24 ,

Since you have already compared the HTML editor system properties, I would check these next:

  1. Dictionary attributes: Open the dictionary entries for problem.work_around and problem.cause_notes and compare the Attributes field between both instances. ServiceNow supports editor.height=250 to set the HTML editor height. The documented default is 64 pixels. Test this in sub-production first.

  2. User preferences: When a user resizes an HTML editor using the + or − controls, a user preference may store its height. Check for field-specific editor height preferences that could override the expected appearance.

  3. Dictionary overrides and inheritance: Check dictionary overrides on the Problem table and relevant inherited fields from Task.

  4. UI customizations: If the above checks do not explain the difference, compare relevant UI Macros, UI Scripts, Client Scripts, and UI Policies between the instances.

Recommended first step: Compare the dictionary attributes and user preferences before modifying any OOTB components.

References:

If you find this helpful , Accept the solution and mark Helpful.

Thankyou
Yamsani Bhavani
ServiceNow Developer - SecOps, GRC, Custom Applications, Now assist

0 Helpfuls