Troubleshooting ServiceNow Form Rendering Issues Using Browser Developer Tools

Jeff Boltz1 · 3 weeks ago

Troubleshooting ServiceNow Form Rendering Issues Using Browser Developer Tools

While investigating a ServiceNow form that was not fully rendering, we developed a repeatable browser-based troubleshooting approach that may help other administrators and developers isolate similar client-side issues.

The symptoms may include:

Reference fields or lookup controls do not respond.
Context menus do not open.
Sections or fields do not display as expected.
UI Policy behavior is incomplete or inconsistent.
The form appears to load, but some controls remain unusable.
A JavaScript exception appears in the browser console during form load.

These symptoms can occur when a client-side error prevents the form from completing its initialization. Possible sources include UI Policies, Client Scripts, UI Policy Actions, UI Scripts, or other custom client-side logic.

1. Start with the Browser Console

Open the affected ServiceNow form and press F12 to open the browser Developer Tools. Select the Console tab, clear any existing messages, and reload the form.

Capture the first JavaScript error and its complete stack trace. The first exception may be more useful than later errors, which could be secondary effects of the original failure.

For example:

TypeError: Example client-side error

at evaluateCondition
at runPolicy
at runPolicyOnLoad

If the stack refers to condition evaluation, policy processing, or an onCondition function, begin reviewing the UI Policies and scripts loaded on the form.

2. Browser Console Command Reference

Category Name Command Purpose

Form Context	Current Table	g_form.getTableName()	Identifies the table currently loaded.
Form Context	Current Record	g_form.getUniqueValue()	Returns the sys_id of the current record.
Form Health	Editable Field Count	g_form.getEditableFields().length	Returns the number of editable fields available to the current user.
Form Health	Missing Fields	g_form.getMissingFields()	Reports fields identified as missing from the current form.
Field Validation	Field Value	g_form.getValue('field_name')	Returns the underlying field value.
Field Validation	Display Value	g_form.getDisplayValue('field_name')	Returns the value displayed to the user.
Field Validation	JavaScript Type	typeof g_form.getValue('field_name')	Shows the JavaScript type returned by g_form.getValue().
Field Validation	Numeric Conversion	Number(g_form.getValue('field_name'))	Tests how the field value converts to a JavaScript number.
Field Validation	Numeric Validation	isNaN(Number(g_form.getValue('field_name')))	Determines whether the converted value is a valid number.
UI Policy Discovery	Policy Count	window.uiPolicies.length	Returns the number of UI Policies loaded on the form.
UI Policy Discovery	Policy Names	window.uiPolicies.map(function(p){ return p.description; })	Lists the descriptions of the loaded UI Policies.
UI Policy Isolation	Run One Policy	window.uiPolicies[0].runPolicy()	Executes one loaded policy. Replace zero with the applicable array position.
Runtime Analysis	Policy Metadata	Object.keys(policy.fp)	Lists the runtime metadata available for the selected policy.
Runtime Analysis	Policy Conditions	policy.fp.conditions	Displays the runtime condition objects.
Runtime Analysis	Condition Field	policy.fp.conditions[0].field	Identifies the field evaluated by the first condition.
Runtime Analysis	Condition Operator	policy.fp.conditions[0].oper	Displays the condition operator.
Runtime Analysis	Condition Value	policy.fp.conditions[0].value	Displays the comparison value.
Runtime Analysis	Condition Type	policy.fp.conditions[0].type	Displays the runtime data type used during evaluation.
Runtime Analysis	Expandable Object View	console.dir(object)	Displays an expandable view of a complex client-side object.

3. Isolate the Failing UI Policy

The following console diagnostic attempts to execute each loaded UI Policy and reports policies that throw an exception:

window.uiPolicies.forEach(function(policy, index) {
    try {
        policy.runPolicy();
    } catch (error) {
        console.error(
            'FAILED:',
            index,
            policy.description,
            error
        );
    }
});

Example result:

FAILED: 12
Example UI Policy

TypeError: Example client-side error

This provides the policy's array position, description, and exception. The individual policy can then be tested directly:

window.uiPolicies[12].runPolicy()

Caution: Executing a UI Policy can change field visibility, mandatory status, read-only status, or field values on the open form. Perform this testing in an appropriate non-production environment whenever possible, do not save unintended changes, and reload the form after testing.

4. Inspect the Runtime Condition

Assign the suspected policy to a console variable:

var policy = window.uiPolicies[12];

Review the policy's available runtime metadata:

Object.keys(policy.fp)

Then inspect the first condition:

policy.fp.conditions[0].field
policy.fp.conditions[0].oper
policy.fp.conditions[0].value
policy.fp.conditions[0].type
policy.fp.conditions[0].term

This can help compare the stored UI Policy configuration with the field, operator, value, and type being evaluated by the client at runtime.

If the policy contains multiple conditions, inspect the other array positions:

policy.fp.conditions[1]
policy.fp.conditions[2]

5. Understanding an “undefined” Console Result

Some commands print useful information and then return:

undefined

This does not necessarily mean that the diagnostic failed. Functions such as console.log(), console.dir(), and Array.forEach() commonly return no value.

Review the information, warnings, and errors displayed above the final undefined.

6. Review the Related Configuration

After identifying the policy, field, or script associated with the exception, review:

The UI Policy definition and encoded condition
UI Policy Actions
True and false scripts
Client Scripts on the affected table
The field dictionary definition
Dictionary overrides
Choice records and underlying values
Scripts that populate, change, or clear the field
Recent configuration or platform changes

Do not assume that the policy description or field label identifies the cause. Compare the stored configuration with the runtime condition metadata and the actual field value.

7. Validate the Correction

Test any proposed correction in an appropriate non-production environment. Include:

A record where the condition evaluates true
A record where the condition evaluates false
A record where the associated field is blank
Each valid choice or state referenced by the condition
Confirmation that the original console error no longer occurs
Confirmation that the intended UI Policy behavior remains correct
Confirmation that reference fields, lookups, context menus, and other form controls remain functional

Recommended Troubleshooting Sequence

Open the affected form and press F12.
Reload the form and capture the first console exception.
Confirm the table and record context using g_form.
Validate fields referenced in the error or suspected client logic.
List the UI Policies loaded on the form.
Execute policies individually to isolate the failure.
Inspect the failing policy's runtime condition metadata.
Review the related UI Policy, Client Script, dictionary, and choice records.
Test the proposed correction in a lower environment.
Document the error, configuration, tests, correction, and results.

Information to Capture for Escalation

Affected table and form view
Record sys_id or reproducible test record
Exact browser console error
Complete JavaScript stack trace
Browser and ServiceNow interface used
Name and sys_id of the suspected UI Policy or Client Script
Runtime field, operator, value, and type
Relevant dictionary and choice configuration
Steps required to reproduce the issue
Results from lower-environment testing
Any workaround tested and its functional result

Important Note

The window.uiPolicies object and its internal properties are useful diagnostic aids, but they are internal client-side implementation details. Their availability and structure may vary by interface or platform release. Use them for troubleshooting and evidence gathering rather than as dependencies in production customizations.

Key Takeaway

Do not stop at the initial stack trace. Browser Developer Tools can be used to validate form state, inspect field values, enumerate loaded UI Policies, reproduce a policy exception, and review the condition metadata used at runtime.

This approach can reduce troubleshooting time by narrowing a broad form-rendering issue to a specific client-side configuration before changes are introduced.

Kieran Anson · 3 weeks ago

If you search for "Debug UI Policies" in your application navigator, you'll find an option to enable verbose logging. This will add additional useful messages into your devtools console

Jeff Boltz1 · 3 weeks ago

Thanks, Kieran! That's an awesome tip, and I really appreciate you taking the time to share it and help move the conversation forward.

I wasn't aware of the Debug UI Policies option when we started this investigation. Looking back, I can absolutely see the value in enabling it once troubleshooting begins pointing toward UI Policy execution.

The additional logging would provide useful insight into condition evaluation and policy processing, and it's something I'll definitely be incorporating into future investigations.

One interesting aspect of this issue is that it didn't initially present itself as a UI Policy problem. The symptoms appeared as a broader form rendering issue, including missing reference controls, lookup behavior problems, missing preview icons, and inconsistent form interactions. Starting from the browser console helped narrow the investigation from a general form issue to a specific client-side failure.

After isolating the failing UI Policy, we found that the condition being evaluated was:

u_override_severity ISNOTEMPTY

against an Integer Choice field. Runtime metadata indicated the field type was:

integer

yet the evaluation path was routed through:

evaluateTermNumber()

which ultimately generated:

Number.prototype.toString requires that 'this' be a Number

What I find particularly interesting is that the issue disappeared when the condition was changed to:

u_override_severity IN 1,2,3,4

This makes me wonder whether field type awareness plays a role in the evaluation path. Conceptually, an ISNOTEMPTY check feels like a generic presence test, while the runtime behavior suggests the platform may have been treating the field as numeric during condition evaluation.

We're still working with Support to better understand whether this represents a platform change, an edge case, or a regression involving how ISNOTEMPTY is evaluated against Integer Choice fields.

Regardless, your suggestion would have been very helpful once we narrowed the issue to UI Policy processing.

Thanks again for the tip and for contributing to the discussion. Hopefully the combination of Debug UI Policies and browser-side analysis gives others a few more tools when troubleshooting similar form-rendering issues.