View

What It Is

Views are saved layout configurations that determine which fields display on forms and lists in ServiceNow. They solve the fundamental problem of presenting the right information to the right users without cluttering interfaces with irrelevant fields. A single table can have dozens of views, each showing a different subset of fields optimized for specific roles, workflows, or devices. Views operate as a presentation layer that sits between the database schema and the user interface, filtering and arranging field visibility without modifying the underlying table structure. This separation allows administrators to create role-specific experiences while maintaining data integrity and a single source of truth.

Views live within the Platform User Interface application as part of ServiceNow's core presentation framework. They're stored in the sys_ui_view table for list views and referenced through form sections for form views. The view system integrates with ServiceNow's role-based access control, device detection, and user preference systems to determine which view renders for each request. Views inherit from parent tables and can be overridden at the child table level, following ServiceNow's standard inheritance patterns. This architectural design allows views to work seamlessly with table extensions, scoped applications, and the broader ServiceNow data model.

Views relate directly to ServiceNow's rendering engine, which evaluates view conditions during page load to determine field visibility and layout. Form views work through the form section system, where each section can have role-based visibility rules that effectively create view-like behavior. List views operate through the list control mechanism, applying column filtering and ordering based on the selected view. The system caches view configurations for performance, but evaluates role and condition logic on each request to ensure security and accuracy. Views also interact with field-level security, UI policies, and data policies to create the final rendered interface.

You cannot function without views in any ServiceNow implementation that serves multiple user types or business processes. Service desk agents need different incident fields than executives viewing dashboards, and ITIL process owners require different change request layouts than implementers. Views become essential when regulatory compliance demands field-level access control, when mobile users need simplified interfaces, or when integration users require API-optimized field sets. Without proper view configuration, users either see overwhelming amounts of irrelevant data or lack access to fields critical for their work. The business necessity becomes acute in large organizations where role-based data access isn't just convenience—it's security and efficiency.

Platform administrators typically manage view configuration, though system architects design the overall view strategy during implementation. Developers create views when building scoped applications or customizing existing functionality. Application developers work with views when creating custom tables or extending platform functionality. The relationship is collaborative: architects define role-based requirements, administrators implement and maintain views, and developers ensure technical functionality. In larger organizations, a platform owner often governs view standards and approval processes to maintain consistency across applications and prevent configuration sprawl.

Recent ServiceNow releases have enhanced view functionality with improved mobile responsiveness and better integration with Workspace and Agent Workspace. Vancouver introduced enhanced list view personalization options and improved performance for complex view hierarchies. Xanadu added better support for dynamic field visibility in Service Portal and improved view inheritance for scoped applications. The Platform Analytics integration now tracks view usage patterns, helping administrators optimize field layouts based on actual user behavior. These improvements maintain backward compatibility while expanding view capabilities for modern ServiceNow interfaces.

Where to Find and Configure It

The primary configuration location for list views is System Definition > List Control where you create, modify, and assign view conditions. Form views are configured through System Definition > Forms by modifying form sections and their role-based visibility. You can also access list views through System Definition > Tables & Columns by opening a table record and navigating to the Views related list. For direct database access, query the sys_ui_view.list table to see all configured views.

In Studio and App Engine Studio, views are managed through the Forms and Lists sections when developing scoped applications. Navigate to Studio > Forms to modify form layouts and section visibility, or Studio > Lists to configure list views for scoped application tables. The Form Designer provides a visual interface for arranging fields and setting section conditions. You can see views in action by navigating to any list or form and using the view selector dropdown, or by right-clicking on lists and selecting Configure > List Layout to modify the current view.

How It Works Step by Step

Views operate through a hierarchical evaluation system that runs during page rendering. When a user loads a list or form, ServiceNow's presentation engine queries available views for that table, evaluates each view's role and condition requirements against the current user context, and selects the most specific matching view. The system checks user roles, device type, and any custom conditions defined in the view configuration. If multiple views match, ServiceNow applies a precedence order based on specificity and condition complexity.

For list views, the system builds the column set based on the selected view's field configuration and applies any user personalizations on top. Form views work differently—they modify section visibility and field arrangement within existing form layouts rather than replacing the entire form structure. The rendering engine caches view metadata but evaluates security and conditional logic on each request to ensure real-time accuracy. This approach balances performance with security, allowing dynamic role-based interfaces without compromising system responsiveness.

The Evaluation Order

1. User requests a list or form page for a specific table
2. System queries sys_ui_view table for views associated with the target table and its parent tables
3. Evaluates each view's role requirements against the user's assigned roles using gs.hasRole() checks
4. Checks device type and responsive conditions if configured for the view
5. Executes any custom condition scripts defined in the view's condition field
6. Selects the most specific matching view based on condition complexity and inheritance hierarchy
7. Applies user personalizations and preferences on top of the base view configuration
8. Renders the final interface with the selected field set and layout

// Example view condition script for role-based field visibility
// This condition shows extended incident fields only to senior agents

function showExtendedIncidentView() {
    var user = gs.getUser();
    var isManager = gs.hasRole('incident_manager');
    var isSeniorAgent = gs.hasRole('itil') && user.getRecord().getValue('years_experience') >= 3;
    
    // Show extended view for managers or experienced agents
    if (isManager || isSeniorAgent) {
        return true;
    }
    
    // Check if incident is high priority and requires senior attention
    if (current && current.priority <= 2) {
        return gs.hasRole('incident_coordinator');
    }
    
    return false;
}

// Return the evaluation result
showExtendedIncidentView();

Real-World Scenarios

Creating Executive Dashboard Views for Incident Management

Executives need a high-level incident overview showing only business impact, priority, and resolution status without technical details that clutter their interface. The requirement is to display incidents with fields like Business Service, Priority, State, Assigned Group, and SLA status while hiding technical fields like Configuration Items, Resolution Code, or detailed work notes.

Navigate to System Definition > List Control and create a new view with Table set to Incident [incident] and Name as Executive Summary. In the Roles field, add executive and director. Configure the Elements field with: number,priority,state,business_service,assignment_group,sla_due,short_description. Set this view as the default by checking Default view for the specified roles.

Mobile-Optimized Change Request Views for Field Technicians

Field technicians using mobile devices need streamlined change request views showing only implementation-relevant fields while hiding administrative details like approval workflows or business justifications. They require quick access to implementation steps, affected CIs, and contact information for efficient field execution.

Create a new view with Table Change Request [change_request] and Name Mobile Implementation. Set Roles to change_implementer and add a Condition: gs.getSession().isMobile(). Configure Elements as number,state,short_description,implementation_plan,cmdb_ci,contact_type,start_date,end_date. Enable Default view to ensure mobile users see this view automatically.

Test the mobile detection condition thoroughly as gs.getSession().isMobile() can behave differently across ServiceNow versions and mobile apps. Consider adding user agent string checks for more precise device detection. Watch for field dependencies—if hidden fields have mandatory requirements, mobile users might encounter validation errors during record updates.

Conditional Asset Views Based on Asset Category

Asset managers need different field sets when viewing hardware versus software assets, with hardware showing physical attributes like location and serial numbers while software assets display license information and deployment details. The system should automatically switch views based on the asset category to prevent interface confusion and improve data entry accuracy.

// View condition for hardware assets
// This shows hardware-specific fields for computer, server, and network equipment

function isHardwareAsset() {
    if (!current || !current.isValidRecord()) {
        return false;
    }
    
    var category = current.getValue('category');
    var hardwareCategories = ['computer', 'server', 'network_gear', 'mobile_device', 'printer'];
    
    return hardwareCategories.indexOf(category) !== -1;
}

// Return true for hardware assets
isHardwareAsset();

Create separate views for hardware and software assets with role asset_manager and the conditional logic shown above. Hardware view elements should include asset_tag,serial_number,location,model_category,install_status,assigned_to while software views include license_type,install_count,allocated_count,software_model,version,support_group. The condition field evaluation happens on each record load, so performance is critical—avoid complex database queries in condition scripts. Consider using reference field values or simple string comparisons instead of related record lookups.

The Classic Mistake

The most destructive view mistake happens when admins go to System UI > Views, right-click the Default view, select Copy, and then modify it for their role-specific view. This creates a view with 40+ fields from the Default view, then they remove most fields to get down to the 8-10 they actually need. The problem isn't visible immediately—the view works fine in the form designer and when testing as an admin.

The failure emerges in production when users complain about slow form loads, especially on large tables like incident or task. ServiceNow's form rendering engine pre-loads field metadata and runs display business rules for every field in the view definition, even hidden ones. When you copy the Default view, the sys_ui_view record retains references to all those unnecessary fields in the sys_ui_section and sys_ui_element records, creating database overhead and unnecessary script execution.

// Create new view from scratch
// Navigate to System UI > Views
// Click New (not Copy)

// View Configuration:
// Name: ESS User View
// Table: incident
// Type: form
// Title: Incident

// Add only required sections:
// Section 1: Basic Information
//   - Number (readonly)
//   - Short description
//   - Description
//   - Priority
//   - State
// Section 2: Assignment
//   - Assignment group
//   - Assigned to

// Result: Clean view with 7 fields instead of inherited 40+

When to Use This vs Alternatives

Views are the correct solution when you need to control field visibility and form layout based on user role, device type, or specific business processes. They provide the cleanest separation between different user experiences without requiring complex scripting or ACL management.

When Views Are the Right Choice

Use views when different user groups need completely different field sets on the same table. ESS users need 8 fields on incident forms while ITIL users need 25—this is exactly what views solve. Client scripts and UI policies fall short here because they create complex show/hide logic that's hard to maintain and debug.

When to Use UI Actions or UI Policies Instead

Choose UI policies when field visibility changes based on form data rather than user identity—like hiding resolution fields until state becomes Resolved. Use UI actions when you need to modify the same form layout with buttons or links. Views can't react to field values or provide dynamic interactions within the same user session.

When You Need Views Plus Other Tools

Complex applications require views for the baseline field layout combined with UI policies for conditional logic within each view. A manager view might show 20 fields by default, but UI policies hide approval fields until the state requires approval. Data policies still enforce field requirements across all views, while ACLs control whether users can modify fields that views make visible.

Platform Interactions & Side Effects

• Display Business Rules execute for every field in the view definition, not just visible fields—hidden fields in copied views still trigger rule evaluation and database queries
• ACLs evaluate against view fields during form load—if a field exists in the view but ACLs deny read access, users see empty fields with no explanation
• Update Sets capture view changes across sys_ui_view, sys_ui_section, and sys_ui_element tables—view modifications create large update sets that can conflict during promotion
• Session state caches view definitions—users must refresh their browser or log out/in to see view changes, clearing the glide_ui_view_cache doesn't always work in multi-node environments
• Mobile views override desktop views when Device field is set to Mobile—users accessing ServiceNow through mobile browsers get mobile views even if desktop views exist for their role
• Related Lists inherit from Default view when no specific view exists for the user's role—this causes ESS users to see full admin-level related lists if not configured properly
• Dictionary overrides affect all views—setting a field's Read only attribute makes it readonly across every view, regardless of view-specific configurations
• Performance degrades when views contain reference fields with complex choice lists—each reference field queries its target table during form load, multiplying database hits
• Audit records in sys_audit only capture changes to fields present in the view used during the update—fields modified via scripts bypass view-based audit logging
• Notification templates can't access field values that aren't included in the view used when the triggering update occurred—missing fields return null in email templates

Debugging and Troubleshooting

View problems manifest as users seeing wrong fields, missing fields, or forms that load slowly. The most common user complaint is "I used to see this field yesterday but now it's gone" which typically means someone modified view assignments or role inheritance. Admins often struggle because view issues don't generate obvious error messages—forms just render differently than expected.

The primary diagnostic location is System Logs > All filtered by Source: UI to see view resolution messages. Enable the glide.ui.debug_ui_16 system property to get detailed logs showing which view ServiceNow selected and why. The Session Debug module under System Diagnostics > Session Debug shows real-time view selection decisions including role evaluation and inheritance logic.

Look for error messages like "View not found for table [table_name] and user [user_sys_id]" or "Multiple views found, using default" in the Application logs. Performance issues show up as slow database queries in System Diagnostics > Stats with high execution times for UI-related operations. The browser's developer console reveals client-side view problems with messages about missing field definitions or failed AJAX calls during form initialization.

Diagnostic Checklist:

• Impersonate the affected user and verify which view loads using browser developer tools to inspect the form's data attributes
• Check role assignments in User Administration > Users and verify view roles match user roles exactly
• Query sys_ui_view table filtered by table name and examine the Roles field for conflicts or overlaps
• Enable glide.ui.debug_ui_16 system property and reproduce the issue to capture view selection logic in logs
• Test with the Default view temporarily by removing role restrictions to isolate view-specific vs. data-specific problems
• Clear the cache using cache.do and select UI View Cache, then test again with fresh browser sessions
• Review recent Update Sets for view-related changes and check if the problem correlates with recent deployments

Quick Reference

• View role matching uses exact role name comparison—inherited roles don't automatically inherit view assignments, each role needs explicit view configuration
• Maximum of 100 sections per view and 50 fields per section before performance degrades significantly on standard ServiceNow instances
• Mobile device detection happens server-side using User-Agent headers—tablets default to mobile views unless glide.ui.mobile.tablet_desktop_ui is enabled
• View selection priority: Role + Device specific, then Role specific, then Device specific, then Default view—first match wins
• Empty view roles field means the view is available to all users—this overrides more specific views unless those views come first alphabetically by name
• Related list views inherit the same role restrictions as form views—users who can't see a form view also can't see its related list data
• Dictionary field attributes override view element settings—a mandatory dictionary field stays mandatory even if the view element sets it optional
• View changes don't automatically invalidate user sessions—users must refresh or re-login to see view modifications, even after cache clearing
• Embedded lists within form views create separate view lookups—each embedded list requires its own view configuration for proper role-based field control
• View export via Update Sets includes all child records from sys_ui_section and sys_ui_element tables—deleting a view requires manual cleanup of orphaned UI elements