ServiceNow List View: Configuration, Filters, Views and Best Practices

Introduction

A ServiceNow List View is one of the most frequently used interfaces for working with records in ServiceNow. Whether an implementation team is managing incidents, service requests, problems, changes, assets, or custom application records, the list view determines how users see, filter, sort, and sometimes edit those records. A well-designed ServiceNow list view can significantly reduce the number of clicks required by an agent or administrator and can make large record sets easier to operate.

For example, an incident manager may need to see Incident Number, Priority, Assignment Group, Assigned To, State, SLA Due, and Updated. A service desk agent may need a different set of columns. Rather than forcing every user to work with the same information, ServiceNow provides mechanisms for personalizing lists and configuring views for different operational requirements.

ServiceNow’s current list experience supports capabilities such as filtering, sorting, grouping, column configuration, list sharing, and actions against selected records.

This article explains ServiceNow List View from an implementation perspective, including how list views work, how to configure columns and filters, how administrators approach role-specific views, and how to troubleshoot common issues.

What Is a ServiceNow List View?

A ServiceNow List View displays multiple records from a ServiceNow table in a tabular format.

For example:

The underlying records could come from tables such as:

• Incident
• Problem
• Change Request
• Requested Item
• Catalog Task
• Knowledge
• Configuration Item
• User
• Asset
• Custom application tables

A list therefore isn’t simply a report. It is an operational interface through which users can find, analyze, and in appropriate circumstances modify records.

ServiceNow documentation and current platform guidance describe list components as supporting filtering, sorting, column controls and, depending on configuration, editing directly within the list.

Key Components of a ServiceNow List View

Before configuring a list, it is important to understand its major components.

1. List Columns

Columns represent fields from the underlying table.

For an Incident list, common columns include:

• Number
• Short Description
• Caller
• Category
• Priority
• State
• Assignment Group
• Assigned To
• Opened
• Updated

Column selection should be driven by the user’s operational requirement rather than by simply exposing every available field.

2. List Rows

Each row represents one record returned by the current filter.

For example:

INC0010021 | VPN Failure | High | In Progress
INC0010022 | Email Issue | Critical | New
INC0010023 | Laptop Issue | Moderate | Assigned

The number of records displayed depends on the query and list configuration.

3. Filters

Filters determine which records appear.

For example:

Active = true
AND
Priority = 1 - Critical
AND
Assignment group = Service Desk

This produces a focused operational list instead of showing thousands of records.

4. Sorting

Sorting determines the order of records.

Examples:

• Priority ascending
• Updated descending
• Created descending
• SLA due date ascending

A service desk supervisor might sort by priority and then by SLA due date to focus on urgent work.

5. List View

A view represents a particular presentation of the list.

Different users or teams may require different information.

For example:

Service Desk View

Number | Caller | Short Description | Priority | State

Incident Manager View

Number | Priority | Assignment Group | Assigned To | SLA | State

The underlying Incident records remain the same; the presentation can differ.

Real-World ServiceNow List View Use Cases

Use Case 1 – Service Desk Incident Management

A service desk handles several thousand incidents every month.

Agents don’t need every Incident field.

The operational list might contain:

• Number
• Caller
• Short Description
• Priority
• State
• Assignment Group
• Assigned To
• Updated

A filter can then show:

Active = true
AND
Assigned to = Me

This gives each agent a focused work queue.

Use Case 2 – Incident Manager SLA Monitoring

An incident manager may need to identify incidents approaching SLA breach.

The list can expose fields such as:

• Incident Number
• Priority
• Assignment Group
• Assigned To
• SLA Due
• State

The filter can focus on active high-priority incidents.

The important implementation principle is that the list should support the decision the user needs to make.

Use Case 3 – Change Management Review

A change manager may need to review upcoming changes.

A useful list could contain:

Instead of navigating into each change individually, the manager can scan the important fields from the list.

Use Case 4 – Custom Application

Suppose an organization creates a custom table called:

u_customer_onboarding

The implementation team could create a list showing:

Request Number
Customer
Region
Owner
Onboarding Stage
Target Date
Status

The same principles used for Incident lists apply to custom tables.

ServiceNow List View Configuration Overview

Before configuring a list, an implementation team should answer several questions.

Step 1 – Identify the Table

Determine the table being displayed.

Examples:

Incident
Change Request
Problem
Requested Item
sys_user
Custom application table

Step 2 – Identify the User Persona

Determine who will use the list.

Examples:

• Service desk agent
• Incident manager
• Change manager
• Application owner
• Platform administrator

Step 3 – Identify Required Columns

Don’t automatically expose 20–30 fields.

Start with fields required for the user’s daily activity.

Step 4 – Define Filter Requirements

Ask:

Which records does the user actually need to see?

Examples:

Active incidents
My incidents
Critical incidents
Open changes
Requests awaiting approval

Step 5 – Determine Whether Inline Editing Is Required

If users need to update a field directly from the list, verify that list editing is appropriate and that security controls permit it.

How to Personalize a ServiceNow List View

One of the simplest list activities is personalizing the columns for an individual user.

ServiceNow provides personal list capabilities that allow users to change column selection and ordering according to their preferences.

Step 1 – Open the Required List

For example:

All → Service Desk → Incidents → All

The exact navigation can vary depending on the ServiceNow application and instance configuration.

Step 2 – Open List Personalization

Open the list personalization controls.

Depending on the ServiceNow interface/version, this may appear through the list menu or personalization control.

Current ServiceNow list interfaces provide controls for configuring list presentation and filtering.

Step 3 – Select Columns

Suppose the default Incident list contains:

Number
Caller
Category
Priority
State
Opened
Updated

You might remove:

Opened
Updated
Category

and add:

Assignment Group
Assigned To

The resulting list becomes:

Number
Caller
Priority
State
Assignment Group
Assigned To

Step 4 – Reorder Columns

Column order matters operationally.

For example, put the identification field first:

Number
Short Description
Priority
State
Assignment Group
Assigned To

An older ServiceNow administration reference also notes the importance of the first non-reference field when designing list layouts.

Step 5 – Save the Personalization

After saving, the user sees the personalized layout.

An important distinction is that personalization does not necessarily mean changing the global/default layout.

A user-specific preference may override the default configuration.

This becomes particularly important during implementation testing.

Creating a Business-Oriented List View

For recurring operational requirements, organizations often need more than personal column changes.

Consider a requirement:

“Create a list for the Incident Management team showing all active Priority 1 and Priority 2 incidents.”

The implementation approach should be:

Step 1 – Open Incident List

Navigate to the relevant Incident list.

Step 2 – Configure the Filter

Build conditions such as:

Active = true
AND
Priority is 1 - Critical OR 2 - High

The exact filter construction depends on the list interface and instance configuration.

Step 3 – Configure Columns

Use:

Number
Short Description
Priority
Assignment Group
Assigned To
State
SLA Due

Step 4 – Save or Configure the View

Give the view a descriptive name such as:

Critical Active Incidents

Avoid vague names such as:

View1
Test View
New View

Good naming becomes especially important when an instance contains dozens of custom views.

Filters in ServiceNow List Views

Filters are arguably the most important part of operational list design.

A poorly designed list may contain thousands of records, while a properly filtered list might show only 20 relevant records.

Basic Filter Example

Active = true

This removes closed/inactive records.

Multiple Conditions

For example:

Active = true
AND
Assignment Group = Network Support
AND
Priority <= 2

This creates a targeted operational queue.

OR Conditions

Suppose the requirement is:

Show Priority 1 or Priority 2 active incidents.

Conceptually:

Active = true
AND
(Priority = 1 OR Priority = 2)

The grouping of conditions matters.

A common implementation mistake is creating an AND/OR structure that technically works but returns unintended records.

Always validate the generated query against known test records.

Sorting and Grouping

Sorting can make the same data significantly easier to consume.

For example:

Priority → Ascending
Updated → Descending

This puts high-priority incidents first while showing recently updated records within the relevant priority.

ServiceNow’s current list component also supports sorting and grouping capabilities where enabled by the interface.

Practical Example

For a Change Manager:

Planned Start → Ascending
Risk → Descending

The manager can quickly identify upcoming high-risk changes.

List Editor and Inline Editing

One useful ServiceNow capability is editing certain fields directly from a list.

For example:

Incident
Priority = 3

could potentially be changed directly in the list to:

Priority = 2

without opening the full form.

However, list editing should not be assumed to work for every field or table.

Security and table configuration still apply, and some tables or fields may not support editing in the list.

Implementation Example

Suppose a team wants agents to update:

State
Assignment Group
Assigned To

from the list.

Before enabling or relying on this approach, test:

1. Field dictionary configuration
2. ACLs
3. User role
4. Client-side behavior
5. Business rules
6. Data policies
7. Reference-field behavior

The goal is to ensure that list editing doesn’t create a different business outcome from editing the same field through the form.

Testing a ServiceNow List View

List configuration should be tested like any other implementation component.

Test Case 1 – Filter Validation

Requirement:

Show active Priority 1 incidents.

Create test data containing:

Expected list:

INC001
INC004

INC002 should be excluded because its priority is 2.

INC003 should be excluded because it is inactive.

Test Case 2 – Column Validation

Verify:

• Required columns are visible
• Unnecessary columns are removed
• Column order is correct
• Reference fields display correctly
• Long text does not unnecessarily disrupt the layout

Test Case 3 – Security Validation

Log in with different roles.

For example:

Agent
Manager
Read-only user
Administrator

Confirm that users see only the records and fields permitted by their security configuration.

A list configuration should never be treated as a replacement for ServiceNow security.

Common ServiceNow List View Problems

Problem 1 – User Cannot See a Column

Possible causes:

• Field isn’t included in the list layout
• User personalization overrides the default
• Field-level security restricts access
• View-specific configuration is being used
• Different table/view is being accessed

Troubleshooting

First compare:

User personalization
        ↓
List configuration
        ↓
Field availability
        ↓
ACL/security

Do not immediately change the dictionary or ACL.

Problem 2 – Administrator Changed the List but User Still Sees the Old Layout

This is a common implementation issue.

A user may already have personalized their list.

Their personal configuration can override the default list configuration. ServiceNow community guidance specifically notes this behavior when default list layouts are changed after users have personalized their lists.

Practical Approach

Test with:

• A clean test user
• The affected user’s personalized configuration
• Administrator access

This helps determine whether the problem is configuration or personalization.

Problem 3 – Filter Returns Unexpected Records

Check the logical structure.

For example, these are not equivalent:

A AND B OR C

and

A AND (B OR C)

Always inspect the generated conditions carefully.

Problem 4 – Inline Editing Doesn’t Work

Check:

• User permissions
• Field configuration
• ACLs
• Table configuration
• Whether the field supports list editing
• Client-side/business-rule behavior

Do not assume that because a field is editable on the form it must also be editable from the list.

Problem 5 – List Becomes Too Wide

This usually happens when too many fields are added.

For example:

Number
Caller
Email
Phone
Description
Comments
Work Notes
Category
Subcategory
Priority
State
Assignment Group
Assigned To
Opened
Updated
Updated By
Location
Department
Company

Technically useful fields can still create a poor operational interface.

Instead, separate the requirements into different views.

Best Practices for ServiceNow List Views

1. Design for a Persona

Don’t create one giant list for everyone.

Ask:

What does this user need to decide or do?

Then design the list around that activity.

2. Keep the Number of Columns Reasonable

A list containing 25 columns may contain more information but can be harder to use.

Prioritize:

• Identification
• Status
• Ownership
• Priority
• Action-related information

3. Use Meaningful View Names

Prefer:

My Active Incidents
Critical Incidents
Pending Change Approval
Unassigned Incidents

instead of:

View1
View2
New View

4. Don’t Use List Configuration to Solve Security Problems

A hidden column is not the same thing as secured data.

If a user should not access a field, implement appropriate ServiceNow security controls rather than merely removing the column.

5. Test With Realistic Data

Ten test records are useful for basic validation, but production-like volumes reveal different problems.

Test with:

• Hundreds or thousands of records
• Different priorities
• Different assignment groups
• Null values
• Long descriptions
• Different user roles

6. Consider Performance

Complex filters and unnecessary reference fields can affect the usability of large lists.

For high-volume tables, review:

• Filter conditions
• Sorting
• Referenced fields
• Query complexity
• Indexing strategy where appropriate

Don’t add fields simply because they are available.

7. Separate Personalization From Global Configuration

This distinction is critical.

Personalization answers:

“What does this particular user want to see?”

Configuration answers:

“What should the application provide as the standard experience?”

Treating both as the same requirement causes confusion during UAT.

8. Validate Security After Configuration

A list should be tested using the same roles that will exist in production.

A technically correct list can still produce an incorrect implementation if users have inappropriate access to records or fields.

Practical Consultant Example

Consider an organization with 500 service desk agents.

The default Incident list contains:

Number
Caller
Category
Subcategory
Priority
State
Assignment Group
Assigned To
Opened
Updated
Configuration Item
Business Service
Location
Description

Agents complain that finding their active incidents takes too long.

Instead of adding more fields, the implementation team defines a focused operational view:

Number
Short Description
Priority
State
Assignment Group
Assigned To
SLA Due

Filter:

Active = true
AND
Assigned to = Me

Sort:

Priority ascending
SLA Due ascending

Now the list directly supports the agent’s daily workflow.

This is the key principle behind good ServiceNow list design:

Configure the list around the user’s work, not around the number of fields available in the table.

Frequently Asked Questions

1. What is a ServiceNow List View?

A ServiceNow List View displays multiple records from a ServiceNow table in a tabular interface. Users can typically filter, sort, personalize columns, and perform supported actions against records.

2. Can users customize ServiceNow List Views?

Yes. ServiceNow provides personalization capabilities that allow users to customize aspects such as visible columns and their order. These personal preferences can affect what an individual user sees even when administrators modify default configurations.

3. Can records be edited directly from a ServiceNow List View?

For supported tables and fields, users may be able to edit records directly through list editing. However, availability depends on configuration, permissions, table/field behavior, and security controls.

Summary

ServiceNow List View is a fundamental platform capability that affects how users interact with operational data. A list is more than a collection of columns: it combines records, filters, sorting, views, personalization, security, and supported list actions into a working interface.

For implementation teams, the most important considerations are:

• Identify the user’s persona.
• Select only operationally useful columns.
• Build filters around real business requirements.
• Use meaningful view names.
• Understand the difference between personalization and global configuration.
• Test filters with realistic records.
• Validate list editing where applicable.
• Test with different user roles.
• Treat security separately from visual configuration.
• Avoid unnecessarily wide and complex lists.

A practical ServiceNow implementation should make the user’s work easier. If an agent has to scan twenty fields to find three pieces of information, the list probably needs redesigning.

The strongest list views are usually simple, purpose-driven, and aligned with the actual operational process.

For additional Oracle Fusion Cloud reference material, use the official Oracle Fusion Cloud Applications documentation. For Oracle Time and Labor specifically, refer to the Oracle Fusion Cloud Time and Labor 26A What’s New documentation for the current 26A feature information.