Field styling in ServiceNow is often misunderstood because there are two very different approaches that people refer to as “field styling”:

1. Form-level styling using Client Scripts (DOM-based)
2. List-level Field Styling using UI Styles & Field Styles (OOTB)

These approaches behave very differently, have different support boundaries, and should not be used interchangeably.

This article explains:

• The difference between form styling and field styling
• Where each approach works
• Common mistakes
• Best practices for real-world implementations

1. Form-Level Styling (Client Script / DOM-based)

This approach is typically used to change how a field looks on the form, for example changing the background color of Short description.

Example

function onLoad() {
    var ctrl = g_form.getControl('short_description');
    if (ctrl) {
        ctrl.style.backgroundColor = 'blue';
        ctrl.style.color = 'white';
    }
}

Supported stylings

Key characteristics

• Works only on Classic / Platform UI
• Applies only to forms
• Uses direct DOM manipulation
• Does not apply to lists or reports

Important limitations

• Not upgrade-safe
• Breaks easily if UI markup changes
• Not supported in:
  
  • Service Operations Workspace
    
  • Agent Workspace
    
  • UI Builder
    
  • Service Portal

This approach should be used sparingly and only for temporary or highly controlled use cases.

2. True Field Styling (UI Styles + Field Styles)

This is the official, supported field styling mechanism in ServiceNow.

It is what produces:

• Colored dots in lists
• Highlighted values (Priority, State, Risk, etc.)
• Consistent visual indicators across lists

3. How Field Styling Works

Defines how the field should look:

• Text color
• Background color
• Font weight
• Icons

Example:

color: orange;
font-weight: bold;

Field Styles

Defines when the style applies:

• Table
• Field
• Condition
• UI Style

Example:

On Incident table, when Priority = 2 → apply yellow indicator

4. Where Field Styling Is Supported

Supported

• List views
• Related lists
• List reports
• Classic UI forms (limited)

Not Supported

• Service Operations Workspace
• Agent Workspace
• UI Builder / Now Experience
• Service Portal

Workspace UIs completely ignore Field Styles by design.

5. One Critical Rule (Very Commonly Missed)

Field Styling Is Global

Once configured, a Field Style:

• Applies to all list views
• Applies to all users
• Applies to all reports using that field

There is no supported way to:

• Apply styling to only one list
• Apply styling to only one report
• Apply styling only on a dashboard

This behavior is by design.

6. When Field Styling Is a Good Fit

Recommended use cases:

• Incident Priority
• Incident State
• Change Risk
• SLA breach indicators
• Approval status

These fields are:

• Global
• Status-driven
• Easy to interpret visually

7. When Field Styling Is the Wrong Tool

Avoid Field Styling for:

• Report-specific coloring
• Role-based visibility
• Workspace UI customization
• Complex or highly contextual logic

For these scenarios, use:

• Performance Analytics widgets
• Dashboard table widgets
• UI Builder visibility rules
• UI Policies / Flows

Final Note

Field Styling is a visual aid, not a UI framework or logic engine.When used correctly, it improves readability and user experience.

When misused, it creates confusion and technical debt.