ServiceNow View: List Views, Form Views, and Database Views

Introduction

A ServiceNow View determines how information is presented to users on the ServiceNow platform. In a real implementation, different users often need different information from the same underlying records. An agent may need Incident Number, Priority, State, and Assignment Group, while a manager may need SLA information, Business Service, and Opened Date. ServiceNow views provide a structured way to present the appropriate fields and information for each audience.

It is important to understand that “view” in ServiceNow can refer to several related concepts. A list view controls how multiple records are displayed, a form view controls how an individual record is displayed, and a database view combines information from multiple tables and is commonly used for reporting and advanced data analysis.

This distinction becomes particularly important during implementation because changing a list layout is very different from creating a database view. Confusing the two can lead to unnecessary customization or performance problems.

ServiceNow’s current platform experience also includes modern workspace and UI Builder experiences, so consultants should understand which type of view they are configuring before making changes. ServiceNow Community guidance confirms that list layouts can be configured through the list’s configuration options, while database views are created separately under the platform’s database-view configuration.

What Is a View in ServiceNow?

A ServiceNow view is essentially a presentation definition that determines which information a user sees and how that information is arranged.

Consider the Incident table:

incident

It can contain many fields:

• Number
• Short description
• Description
• Caller
• Category
• Subcategory
• Priority
• State
• Assignment group
• Assigned to
• Configuration item
• Business service
• Opened
• Updated
• Due date
• SLA-related information

Showing every field to every user would create a poor user experience.

Instead, organizations commonly create different views for different roles.

A view therefore provides a controlled presentation layer over the same underlying data.

The Important Types of ServiceNow Views

For implementation purposes, distinguish these concepts:

The first two primarily affect presentation, whereas a database view changes how related data can be exposed for reporting and querying.

List View vs Form View vs Database View

This is one of the most common ServiceNow interview and implementation questions.

List View

A list view controls the columns displayed when users open a table containing multiple records.

For example:

Incident → All

might display:

Number | Short Description | Priority | State | Assignment Group

The actual incident records have not changed. Only their presentation has changed.

Form View

A form view controls the layout of an individual record.

For example, opening:

INC0012345

could display sections such as:

• Incident Information
• Caller Information
• Assignment
• Resolution Information
• Related Records

Different roles can potentially work with different form layouts.

Database View

A database view is different.

Suppose a reporting requirement asks for:

• Incident Number
• Incident Short Description
• Assignment Group
• SLA Definition
• SLA Stage
• SLA Due Date

If the required information resides in multiple tables, a database view can define relationships between those tables for reporting purposes.

ServiceNow documentation material describes database views as a mechanism for defining table joins for reporting.

Key Features of ServiceNow Views

1. Role-Oriented Information Presentation

Views allow organizations to present information according to user responsibilities.

An L1 agent does not necessarily need the same columns as an incident manager.

This helps reduce visual clutter and makes operational work faster.

2. Configurable List Columns

Administrators can configure:

• Columns displayed
• Column order
• Available fields
• Different named views

ServiceNow Community examples show the use of Configure → List Layout to add, remove, and rearrange columns.

3. Multiple Views for the Same Table

A single table can support multiple views.

For example:

• agent_view
• manager_view
• technical_view

Each can expose a different set of fields.

4. Filtering and Views Work Together

A view controls presentation, while a filter determines which records are displayed.

For example:

View

Number | Priority | State | Assignment Group

Filter

Active = true

The result is a focused operational list.

5. Database Views Support Multi-Table Reporting

Advanced reporting requirements sometimes require information from more than one table.

A database view can establish joins between tables and expose combined information for reporting.

Real-World ServiceNow View Use Cases

Use Case 1: Service Desk Agent View

A company has 500 service desk agents.

The default Incident list contains many columns that agents rarely use.

The implementation team creates an agent-focused list view containing:

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

The result is a cleaner operational list.

Implementation benefit

Agents spend less time scanning irrelevant information.

Use Case 2: Incident Manager View

Incident managers need a different perspective.

Their view might contain:

• Number
• Priority
• Business Service
• Assignment Group
• Assigned To
• State
• Opened
• Updated
• SLA-related information

The manager can then combine the view with filters such as:

Priority is 1 or 2

and

State is not Closed

This provides an operational management queue.

Use Case 3: Multi-Table Reporting with a Database View

Consider an organization that wants a report combining information from:

• Incident
• User
• Assignment Group
• SLA-related tables

The reporting team needs a unified dataset rather than manually exporting and combining records.

A database view can be designed to join the relevant tables and expose fields needed for reporting.

This is significantly different from merely changing the Incident list layout.

ServiceNow View Configuration Overview

Before creating or changing a view, perform an impact assessment.

Basic list/form view setup

You should identify:

1. Target table
2. Target user population
3. Required fields
4. Required field order
5. Existing views
6. Whether the change should be personal or global
7. Security implications
8. Workspace/application context
9. Performance implications

Database view setup

For a database view, additionally identify:

1. Tables to join
2. Join relationships
3. Join direction
4. Join conditions
5. Fields required for reporting
6. Expected record volume
7. ACL/security implications
8. Reporting frequency
9. Performance considerations

A database view should not be created simply because a report needs multiple tables. First verify whether the reporting requirement can be met using existing reporting capabilities.

Step-by-Step: Create a ServiceNow List View

The exact UI can vary between platform experiences and releases, but the underlying configuration concept remains consistent.

Step 1 – Open the Required List

Navigate to a table such as:

All → Service Desk → Incidents → All

Open the Incident list.

You will see existing columns and records.

Step 2 – Open List Configuration

Use the list’s configuration/context controls and select:

Configure → List Layout

Depending on the interface, the list configuration may be available through the list action/context menu rather than the older right-click pattern. Recent ServiceNow Community guidance reflects this evolution of the list interface.

Step 3 – Select or Create a View

In the List Layout configuration, identify the view you want to modify.

For example:

Default

For a new view, create a descriptive view name.

Example:

service_desk_agent

ServiceNow guidance indicates that view names should follow the platform’s naming requirements rather than using arbitrary display labels.

Step 4 – Select the Required Fields

For an agent-oriented Incident list, select:

The sequence matters.

Put the fields agents use most frequently toward the left.

Step 5 – Save the Configuration

Save the List Layout.

Open the resulting list and verify that the columns appear in the expected sequence.

A useful implementation practice is to test the view using an actual target-user role instead of testing only as an administrator.

Step-by-Step: Configure a Form View

A form view is useful when different groups need different arrangements of fields.

Step 1 – Open a Record

Navigate to:

All → Service Desk → Incidents → All

Open an Incident record.

Step 2 – Open Form Layout Configuration

Use the form’s configuration/context options and open:

Configure → Form Layout

The available fields and sections can then be arranged according to the required design.

Step 3 – Arrange Fields

For an agent form, you might organize the information as:

Incident Information

• Number
• Short Description
• Description
• Category
• Subcategory

Assignment

• Assignment Group
• Assigned To
• Configuration Item

Resolution

• Resolution Code
• Resolution Notes
• Resolved By
• Resolved

The purpose is not simply to display more fields. The objective is to arrange information according to the business process.

Step-by-Step: Create a ServiceNow Database View

A database view is an advanced configuration and should normally be handled by an experienced ServiceNow administrator/developer.

Step 1 – Navigate to Database Views

Navigate to:

System Definition → Database Views

Then select:

New

ServiceNow implementation material commonly uses this navigation path for creating database views.

Step 2 – Define the Database View

Enter values such as:

Use a meaningful technical name.

Avoid names such as:

test_view

or

new_view1

because the purpose becomes unclear later.

Step 3 – Add Participating Tables

Suppose the reporting requirement involves Incident and SLA information.

The database view’s participating tables can be configured with an order and aliases/prefixes appropriate to the implementation.

A simplified conceptual design might be:

Incident
   |
   | Incident reference
   |
Task SLA
   |
   | SLA definition reference
   |
Contractual SLA / Definition

The exact tables and relationships depend on the business requirement and ServiceNow application implementation.

Step 4 – Define Join Conditions

The participating tables must be logically connected.

For example, a relationship can conceptually look like:

incident.sys_id = task_sla.task

The actual join condition must be based on the table schema in the target instance.

Do not copy a join condition from another implementation without validating the dictionary and relationship in your environment.

ServiceNow database-view examples show that participating tables can be ordered and connected through where clauses/join conditions.

Step 5 – Test the Database View

After configuration, use the available testing/list mechanism to verify the returned data.

Check:

• Number of records
• Duplicate records
• Missing records
• Join accuracy
• Field values
• Performance
• Security behavior

This step is extremely important.

A technically valid join can still produce incorrect business results.

Testing ServiceNow Views

Testing should cover both presentation and data correctness.

Test 1 – List View

Open the target list as the intended user.

Verify:

• Correct columns
• Correct order
• Correct records
• Filters work
• Sorting works
• Reference fields display correctly

Expected result

The user sees only the intended columns in the expected sequence.

Test 2 – Form View

Open several records representing different business conditions.

Test:

• New record
• In-progress record
• Resolved record
• Record with missing optional data
• Record with reference fields

Confirm that required sections and fields are displayed correctly.

Test 3 – Database View

Run the database view with a known test dataset.

For example:

Incident: INC0012345
Assignment Group: Network Support
SLA: Resolution SLA
Stage: In Progress

Confirm that the database view returns the expected combination.

Important validation

Suppose one incident has three matching SLA records.

A poorly designed report could return:

INC0012345
INC0012345
INC0012345

This may be technically correct at the database level but misleading to a business user expecting one row per incident.

Always establish the intended reporting grain before designing a database view.

Common ServiceNow View Implementation Challenges

1. Confusing Personalization with Global Configuration

One of the most common issues is changing a user’s personalized list and expecting every user to see the same configuration.

Personalized list settings can be user-specific, while administrator-configured layouts can establish the default configuration. ServiceNow Community discussions highlight this distinction in practical implementation scenarios.

Consultant recommendation

Always ask:

“Should this change affect only me, a role/group, or all users?”

That question prevents many configuration mistakes.

2. Modifying the Wrong View

A developer may modify the Default view while users are actually accessing a custom view.

Before making changes, confirm:

• Application
• Table
• View name
• User role
• Workspace/application context

3. Too Many Columns

Adding every requested field to a list makes the view difficult to use.

A better approach is to identify the fields required for the user’s immediate decision-making process.

4. Incorrect Database Joins

Database-view problems commonly arise from incorrect relationships.

Symptoms include:

• Duplicate records
• Missing records
• Unexpected record counts
• Slow reports

The solution is to validate the join against actual sample records.

5. Performance Problems

Joining large tables can become expensive.

Before implementing a database view, estimate:

• Number of records
• Frequency of reporting
• Number of joins
• Filter selectivity
• Required reporting window

Do not assume that a database view will automatically be efficient simply because it simplifies report development.

6. Security and ACL Considerations

A view should not be treated as a way to bypass security.

When sensitive information is involved, test the resulting data under the same roles used by the target users.

Database-view security behavior can have additional considerations, so security testing should be part of the design rather than an afterthought. ServiceNow’s database-view documentation material specifically discusses ACL considerations.

Best Practices for ServiceNow Views

1. Design for the User Role

Do not start with:

“Which fields can we display?”

Start with:

“What decisions does this user need to make?”

Then select fields accordingly.

2. Keep List Views Focused

A good operational list normally prioritizes the fields that users inspect repeatedly.

3. Use Consistent Naming

Use organization-approved naming standards for custom views.

For example:

agent_incident
manager_incident
technical_incident

rather than:

view1
view2
newview

4. Document Custom Views

Maintain a simple configuration document containing:

• Table
• View name
• Purpose
• Target users
• Columns
• Filters
• Owner
• Change reference

5. Validate Before Changing the Default

Changing the default list layout can affect many users.

Test custom requirements first.

6. Avoid Database Views for Simple Presentation Problems

If the requirement is simply:

“Show Priority before State.”

You need a list layout—not a database view.

If the requirement is:

“Combine fields from multiple related tables for reporting.”

A database view may be appropriate.

7. Test With Realistic Data

Five test records are rarely enough for a reporting view.

Use representative data volumes and edge cases.

8. Consider Modern Experiences

ServiceNow implementations increasingly use workspaces and UI Builder-based experiences. Do not assume that a traditional platform list configuration automatically represents every modern workspace experience. Current ServiceNow Community material also documents newer list presentation options in UI Builder.

ServiceNow View Interview Questions

1. What is a ServiceNow View?

A view defines how ServiceNow information is presented to users. Depending on context, it can refer to a list view, form view, or database view.

2. What is the difference between a list view and a form view?

A list view controls multiple records and their columns. A form view controls the layout of a single record.

3. What is a database view?

A database view defines relationships between multiple tables so their data can be queried together, commonly for reporting.

4. Can one table have multiple views?

Yes. Different views can present different fields or arrangements for different business requirements.

5. Does changing a list view change the database?

No. A list layout changes presentation, not the underlying business record.

6. Why would you create a database view?

A database view can be useful when a reporting requirement needs data from multiple tables and the required relationship needs to be exposed as a combined reporting source.

7. What happens if a database view has an incorrect join?

It can produce missing records, duplicate records, or misleading results.

8. Can a database view improve reporting?

It can simplify access to related data for suitable reporting requirements, but performance must be evaluated for the actual tables and data volume.

9. What should you check before changing a default list layout?

Check the affected table, view, user population, existing personalization, application context, and impact on current users.

10. Why are database views considered more advanced?

They require understanding of table relationships, joins, reporting grain, security, and performance—not just user-interface configuration.

FAQ

1. What is the difference between ServiceNow View and List Layout?

A view is the named presentation configuration, while the list layout defines the fields and their order within a list view. In practice, administrators commonly use List Layout configuration to build or modify list views.

2. Can I create a custom ServiceNow View?

Yes. Administrators can create custom list/form views according to the application’s configuration and user requirements. The exact configuration experience depends on the ServiceNow interface and application.

3. When should I use a Database View?

Use a database view when you have a legitimate requirement to expose related information from multiple tables together, particularly for reporting. Do not create one merely to customize the columns of a single table.

Summary

ServiceNow View is a fundamental platform concept that becomes increasingly important as an implementation grows. A simple list-view change may look like a small UI adjustment, but poorly designed views can create confusion, inconsistent user experiences, reporting problems, and unnecessary customization.

The key distinction is straightforward:

• List View → controls how multiple records are displayed.
• Form View → controls how one record is displayed.
• Database View → combines information from multiple tables for querying/reporting.
• Workspace/UI Builder presentation → provides modern application-specific user experiences.

For implementation projects, start with the business user’s requirement, identify the correct type of view, validate the target table and existing configuration, and test the result with representative users and data. For database views, pay particular attention to join logic, reporting grain, security, and performance.

For additional platform information, refer to the official ServiceNow documentation and the relevant product documentation for your installed ServiceNow release. Also review the current ServiceNow Community guidance when UI behavior differs between platform experiences.