Next Experience

What It Is

Next Experience is ServiceNow's modern UI framework that provides a unified interface layer across all ServiceNow applications, replacing both the Classic UI and Service Portal architectures with a single, component-based system. It solves the fragmentation problem where organizations had to maintain separate UI configurations for different user types — agents used Classic UI while customers and employees used Service Portal widgets with completely different design patterns and maintenance overhead. Next Experience consolidates this into workspace-based layouts where the same underlying components can be configured once and rendered appropriately for different user contexts, whether they're accessing ServiceNow through the agent interface, employee portal, or mobile applications.

Architecturally, Next Experience lives in the Now Experience Framework application scope and operates as a rendering engine that sits above ServiceNow's data layer but below the presentation layer. It integrates with the UI Framework application and connects to ServiceNow's standard GlideRecord APIs, business rules, and ACLs — your existing server-side logic doesn't change. The framework uses declarative configuration stored in tables like sys_ux_page_registry, sys_ux_lib_component, and sys_ux_screen to define UI components, page layouts, and workspace configurations that get compiled into the browser-rendered interface.

The relationship to ServiceNow's data model remains unchanged — Next Experience components still read from and write to the same tables using the same APIs, but the presentation layer is completely reimagined. Instead of form sections and related lists, you configure workspaces with flexible layouts that can display record data, lists, charts, and custom components in responsive grids that adapt to screen size and user context. The framework handles responsive design automatically, eliminating the need to maintain separate mobile views or worry about how forms render on different devices.

You cannot function without Next Experience in scenarios where user experience consistency is critical to adoption — specifically when you have multiple user types accessing the same data through different interfaces, when you need mobile-responsive interfaces that don't require separate mobile app development, or when you're implementing employee or customer portals that need to feel modern and integrated rather than bolted-on. Organizations migrating from Service Portal find Next Experience essential because it provides the same customization flexibility without requiring separate widget development and maintenance cycles. The framework becomes mandatory when you need workspace-based experiences for specific roles like HR case management, facilities requests, or custom application development where form-based interfaces are insufficient.

Platform owners typically control the overall Next Experience strategy and application activation, while ServiceNow administrators handle workspace configuration, page layouts, and component setup through the UI Builder interface. Developers get involved when custom components are needed or when integrating Next Experience pages with existing applications requires scripted logic or custom data sources. The division is cleaner than Service Portal development — most Next Experience configuration is declarative and doesn't require JavaScript development, but developers can still create custom components using the Component Development Environment when business requirements exceed what's available out of the box.

Recent releases have significantly expanded Next Experience capabilities — Vancouver introduced Advanced Work Assignment integration and improved workspace sharing, while Washington added enhanced mobile experience optimization and better performance for complex workspaces. Xanadu brought major improvements to the UI Builder with better component library management and streamlined page creation workflows. The most significant change is the deprecation timeline for Service Portal — while existing Service Portal implementations continue to work, ServiceNow is directing all new portal development toward Next Experience, making migration planning a critical consideration for organizations currently using custom widgets and portal pages.

Where to Find and Configure It

Primary configuration happens in All > Now Experience UI Framework > UI Builder where you create and modify workspaces, configure page layouts, and manage component libraries. Navigate to All > Now Experience UI Framework > Experiences to manage experience definitions and activate Next Experience for different user types or applications. For workspace administration, go to All > Now Experience UI Framework > Workspaces to view, clone, or modify existing workspace configurations.

Component development and management happens in All > System Applications > Studio when building custom components, or All > App Engine > App Engine Studio for citizen developer component creation. Access the underlying data model through All > System Definition > Tables and filter for tables starting with sys_ux_ to see workspace definitions, component configurations, and page registrations. Experience activation and user assignment is controlled through All > System Properties > UI Properties where you'll find Next Experience activation toggles for different interfaces.

See Next Experience in action by navigating to any activated workspace — if you've enabled it for agents, open an incident record and look for the workspace-based layout instead of traditional form sections. For scoped applications, Next Experience components inherit the scope of the application they're created in, but workspace configurations in the global scope can reference components from any accessible scope. The key difference is that scoped workspaces can only be modified within their originating scope, while global workspaces can incorporate components from multiple scopes but require appropriate ACL permissions for cross-scope component access.

How It Works Step by Step

Next Experience operates as a rendering pipeline that transforms declarative workspace configurations into dynamic user interfaces. When a user requests a page, ServiceNow first determines which experience is active for that user's role and context, then loads the appropriate workspace definition from the sys_ux_screen table. The framework reads the workspace's layout configuration, identifies all required components, and builds a component tree that defines what data needs to be fetched and how the interface should be structured.

The component execution model is event-driven and reactive — each component maintains its own state and can communicate with other components through a shared data context or explicit event passing. Unlike traditional ServiceNow forms where everything loads sequentially, Next Experience components can load independently and update themselves based on user interactions or data changes elsewhere in the workspace. This creates a more responsive experience but requires careful attention to component dependencies and data flow design.

Caching behavior differs significantly from Classic UI — Next Experience caches component definitions and workspace configurations in the browser, but data fetching respects standard ServiceNow caching policies and ACL evaluation happens server-side for every data request. The framework includes fallback mechanisms that render basic layouts when component definitions are missing or when users lack appropriate permissions, preventing complete interface failures but potentially showing reduced functionality.

The Execution Order

1. User requests a page URL, ServiceNow identifies the target table and record context
2. Experience resolver determines which Next Experience workspace applies based on user role, device type, and URL patterns
3. Workspace definition loads from sys_ux_screen table, framework parses component tree and layout structure
4. ACL evaluation runs for each component and data source, determining what user can see and modify
5. Initial data fetching occurs for primary record and any components requiring server-side data
6. Browser receives complete workspace definition and data payload, begins component rendering
7. Components initialize in dependency order, establish event listeners and data bindings
8. Workspace becomes interactive, subsequent data changes trigger component updates without full page reloads

// Common pattern for workspace data providers
(function() {
    'use strict';
    
    data.table = options.table || 'incident';
    data.sys_id = options.sys_id || '';
    data.fields = options.fields || 'number,state,short_description,assigned_to';
    
    if (data.sys_id) {
        var gr = new GlideRecord(data.table);
        if (gr.get(data.sys_id)) {
            data.record = {};
            var fieldsArray = data.fields.split(',');
            for (var i = 0; i < fieldsArray.length; i++) {
                var field = fieldsArray[i].trim();
                data.record[field] = gr.getDisplayValue(field);
            }
        }
    }
})();

Real-World Scenarios

Creating Custom HR Case Workspace for Employee Requests

HR needs a specialized workspace for handling employee cases that shows case details, related employee information, and approval workflow status in a single view without requiring agents to navigate between multiple forms. The workspace should work equally well on desktop and tablet devices for HR managers working remotely.

Navigate to All > Now Experience UI Framework > UI Builder and click Create new > Workspace. Set the workspace name to 'HR Case Management' and select sn_hr_core_case as the primary table. Add a three-column layout with the record form in the left column, employee details component in the middle column, and approval workflow component in the right column. Configure the workspace to activate for users with the sn_hr_core.case_read role by setting the experience conditions in the workspace properties.

Watch for mobile rendering issues with three-column layouts — they automatically collapse to single column on smaller screens, which might not be ideal for workflow components. Test the workspace performance with large approval histories since the workflow component can become slow with extensive approval chains. Ensure the workspace doesn't conflict with existing HR application customizations by checking the experience priority settings in the workspace configuration.

Replacing Service Portal Page with Next Experience Customer Portal

Organization needs to migrate a custom Service Portal page that displays user's requests, approvals, and knowledge articles to Next Experience for better mobile support and reduced maintenance overhead. The existing portal page uses custom widgets that need equivalent functionality in Next Experience.

Create a new Next Experience workspace in UI Builder with a dashboard-style layout using multiple list components. Configure a 'My Requests' list component pointing to sc_request table with filter requested_by=javascript:gs.getUserID(). Add a 'My Approvals' component using sysapproval_approver table filtered by approver=javascript:gs.getUserID()^state=requested. Include a knowledge search component configured for employee-accessible articles. Set up the workspace to activate for authenticated users through All > Now Experience UI Framework > Experiences and create an experience record that activates this workspace for the employee portal context.

Pay attention to knowledge base ACLs — Next Experience components respect the same ACL structure as Classic UI, so ensure your knowledge articles have proper can_read_user_criteria configured. Test the workspace performance with users who have extensive request histories since large datasets can impact load times. Consider implementing pagination in your list components and verify that the URL routing works properly for direct links to specific requests from email notifications.

Implementing Multi-Table Workspace for Major Incident Management

Major incident commanders need a unified workspace that displays the primary incident record, all related problems and changes, impacted services, and real-time communication threads without switching between different interfaces. The workspace should support collaborative editing and provide quick access to escalation procedures.

Design a workspace with the incident form as the primary component, then add related list components for problem and change_request tables using reference field relationships. Configure a service impact component using a custom data provider that queries the cmdb_rel_ci table to show downstream service dependencies. Add an activity stream component to display real-time updates and enable the collaboration features in the workspace settings. Create role-based access by setting the workspace to activate only for users with major_incident_manager role and configure conditional display rules that only show this workspace for Priority 1 incidents.

Monitor workspace performance carefully since complex CMDB queries can create timeouts, especially when showing large service dependency trees. The activity stream component can become a bottleneck with high-frequency incident updates, so consider implementing filters or pagination. Ensure your custom data providers handle ACL checking properly since major incident workspaces often need to display data from multiple security domains, and test the workspace behavior when users lose incident commander privileges mid-session.

The Classic Mistake

Admins commonly create custom workspace pages and try to embed legacy Service Portal widgets directly alongside Next Experience components. They'll configure a Workspace Experience record with multiple UX Page Definition entries, setting the Content Type field to Component for some sections and Service Portal Widget for others within the same layout container.

// UX Page Definition records for same workspace page
// Record 1:
Content Type: Component
Component: now-record-list
Container: main-content
Order: 100

// Record 2: 
Content Type: Service Portal Widget
Widget ID: widget-cool-chart  
Container: main-content
Order: 200

// Record 3:
Content Type: Component  
Component: now-button-bar
Container: main-content
Order: 300

// This creates CSS conflicts and broken Angular scopes

Users see broken layouts, components that won't load, or JavaScript errors in the browser console. ServiceNow's Next Experience framework uses a different Angular context and CSS scoping system than Service Portal widgets, creating conflicts when they share the same DOM container. The now-loader service can't properly initialize both component types simultaneously in the same container scope. This isn't obvious because individual components work fine in isolation during testing.

// Use separate containers or stick to one content type per layout
// Option 1: Separate containers
Content Type: Component
Component: now-record-list
Container: left-panel
Order: 100

Content Type: Service Portal Widget
Widget ID: widget-cool-chart
Container: right-panel  
Order: 100

// Option 2: Convert widgets to Next Experience components
Content Type: Component
Component: now-record-list
Container: main-content
Order: 100

Content Type: Component
Component: custom-chart-component
Container: main-content
Order: 200

When to Use This vs Alternatives

Next Experience is the right choice when you're building user interfaces for internal employees who need consistent, workspace-based interactions with ServiceNow data and workflows. It excels at form-heavy processes, record management, and integrating multiple ServiceNow applications into unified workspaces where users spend significant portions of their workday.

Choose Next Experience for Internal Users

Use Next Experience when building agent interfaces, employee service centers, or administrative dashboards where users need deep ServiceNow platform integration. The component library, workspace layouts, and declarative configuration system handle complex form interactions and record relationships better than Service Portal's widget-based approach. Service Portal falls short here because it requires custom widget development for platform-native behaviors that Next Experience provides out-of-the-box.

Use Service Portal for External-Facing Sites

Choose Service Portal when building customer-facing portals, vendor interfaces, or public-facing request systems where branding flexibility and custom user experiences matter more than platform integration depth. Service Portal's widget architecture allows complete control over HTML, CSS, and user flows that external users expect. Next Experience's workspace paradigm doesn't translate well to external user journeys that need custom branding and simplified navigation patterns.

Hybrid Approach for Complex Organizations

Deploy both when you have distinct internal and external user bases with different interface requirements. Use Next Experience for employee-facing ITSM, HRSD, and CSM agent interfaces while maintaining Service Portal for customer self-service, vendor onboarding, and public knowledge bases. The key is maintaining clear separation—never try to embed one framework within the other's page structures.

Platform Interactions & Side Effects

• ACL evaluation occurs at the component level, checking sys_ui_action, sys_ui_section, and table-level permissions for each rendered component independently
• Business Rules execute normally but UI Actions configured for Classic UI don't automatically appear in Next Experience forms—they need explicit Available on field configuration
• Client Scripts and UI Policies work but onChange events fire differently due to Next Experience's reactive form handling, potentially breaking timing-dependent scripts
• Update Sets capture sys_ux_screen, sys_ux_page_definition, and sys_ws_definition records but workspace customizations don't migrate cleanly between instances with different data
• Session state management differs from Classic UI—browser tab isolation means workspace preferences stored in sys_user_preference don't sync across tabs in real-time
• Performance monitoring shows as separate entries in syslog_transaction with type=REST rather than traditional page loads
• Custom components require proper sys_ux_lib_* table entries and break completely if the Now CLI deployment process is interrupted
• Notifications triggered from Next Experience forms include different event.request context data, potentially breaking notification scripts that depend on Classic UI request parameters
• Browser caching for Next Experience assets is more aggressive than Classic UI, requiring cache.do flushes during development or users see stale component definitions
• Application menu integrations write to sys_app_module but workspace navigation uses sys_ux_screen_type associations, causing menu items to disappear if not properly configured for both contexts

Debugging and Troubleshooting

The most common Next Experience failures manifest as blank workspace pages, components that render empty containers, or JavaScript console errors mentioning now-loader or snc-component-loader. Users typically report that they can see the workspace shell and navigation but the main content area shows loading spinners indefinitely. From an admin perspective, the workspace appears correctly configured in sys_ux_screen but something in the component chain is breaking the rendering process.

Start troubleshooting by checking System Logs > All for entries containing uxf or component in the source field. Enable the com.snc.ux.debug system property to get detailed component loading information. Browser developer tools will show specific errors like "Failed to load component definition" or "Component [name] not found in registry," which point directly to missing or misconfigured sys_ux_lib_component records.

Performance issues typically appear as slow workspace loading times or components that take several seconds to populate with data. Check the Stats > Slow Queries module for REST API calls to /api/now/ui/ endpoints that exceed reasonable response times. The Network tab in browser dev tools will show individual component API calls—look for 4xx or 5xx responses that indicate permission problems or missing data sources.

Diagnostic Checklist

• Verify sys_ux_screen record exists and Active field is true for the problematic workspace
• Check sys_ux_page_definition records have valid Component field values that match existing component names
• Confirm user has ux_page_reader role and ACL permissions for referenced tables in components
• Test workspace URL directly by appending ?sysparm_debug=true to see detailed loading information
• Clear platform cache via cache.do and browser cache, then test with incognito/private browsing window
• Review custom component sys_ux_lib_component records for proper JSON syntax in component definition fields
• Validate that workspace Application scope matches the scope of referenced components and data sources

Quick Reference

• Maximum of 50 components per workspace page—exceeding this causes performance degradation and potential browser memory issues
• Component loading timeout is hardcoded to 30 seconds—components that don't initialize within this window show as empty containers
• Workspace preferences are stored per-user in sys_user_preference with names starting with workspace. and persist across sessions but not across different browsers
• Custom component names must be unique across all applications in the instance—duplicate names cause the last-loaded definition to override previous ones
• Next Experience REST API calls bypass Business Rule before query rules but still execute before display and after query rules
• Browser back button behavior is controlled by the com.snc.ux.history_management system property—disabled by default to prevent workspace state conflicts
• Component CSS isolation uses Shadow DOM where supported, falling back to scoped CSS classes prefixed with snc- in older browsers
• Workspace URL structure uses /now/workspace/ followed by the workspace ID—bookmarking requires including the full path with workspace context
• Mobile responsiveness breaks at viewport widths below 768px unless components explicitly include mobile-responsive CSS properties
• Print functionality requires custom CSS media queries—default Next Experience styles hide most content in print layouts