Application Navigator

What It Is

The Application Navigator is ServiceNow's hierarchical menu system that organizes platform functionality into applications, modules, and sub-modules, providing users with structured access to tables, lists, dashboards, and custom functionality. It solves the fundamental problem of navigating thousands of platform features by grouping related functionality into logical applications like Incident, Change, or System Definition. The navigator dynamically filters menu visibility based on user roles, ensuring users only see functionality they can access while maintaining a consistent organizational structure across the entire platform.

Architecturally, the Application Navigator lives in the global scope and is managed through three core tables: sys_app_application (applications), sys_app_module (modules), and sys_app_category (categories). These tables define the menu structure, visibility rules, and navigation targets that appear in both Classic UI's left navigation panel and Next Experience's All menu. The navigator integrates with ServiceNow's role-based access control system, reading user roles at runtime to determine which applications and modules to display, while supporting both out-of-box platform functionality and custom scoped applications.

The underlying data model connects applications to modules through a parent-child relationship, where each module record contains an application reference field pointing to its parent application record. Modules define their navigation targets through fields like link_type (list, new, dashboard, etc.) and table or query fields that specify what loads when clicked. The execution environment evaluates role conditions stored in the roles field of each application and module record, creating a dynamic menu that refreshes based on the current user's session context and role assignments.

You cannot function without the Application Navigator in any enterprise ServiceNow implementation because it's the primary method users access platform functionality — there's no alternative way for end users to reach incident lists, change forms, or configuration tables without either navigator access or direct URL knowledge. Custom applications become completely inaccessible to users if they lack proper application and module records, making navigator configuration essential for any scoped application deployment. The business necessity becomes critical during role-based implementations where different user groups need access to different subsets of functionality; without proper navigator configuration, you'll have users unable to access tools they need or seeing functionality they shouldn't touch.

Platform owners typically manage out-of-box application and module records, while system administrators handle role assignments and custom module creation for business-specific needs. Developers working in scoped applications automatically get application records created when they build new applications, but they must manually create module records to expose their custom tables and functionality in the navigator. The relationship between these roles matters because improper module configuration by developers can create security gaps, while overly restrictive role assignments by admins can block legitimate user access to necessary functionality.

Vancouver introduced significant changes to navigator behavior in Next Experience, moving from the persistent left panel to the All menu accessible via the grid icon. The filter navigator functionality now includes enhanced search capabilities that index module descriptions and keywords, not just titles. Xanadu builds on this with improved application grouping and the ability to pin frequently accessed modules, but the underlying data model and configuration approach remain consistent with Classic UI — the same application and module records control navigation in both interface versions.

Where to Find and Configure It

Primary configuration happens at System Definition > Applications for managing application records and System Definition > Modules for creating and modifying individual menu items. Access the underlying tables directly at sys_app_application.list and sys_app_module.list when you need bulk operations or advanced filtering capabilities.

For scoped application development, access navigator configuration through System Applications > Studio where you can create modules within your application scope, or use System Applications > App Engine Studio for low-code module creation with guided workflows. Studio provides the Application Files > Application Menus section where you build navigation structure specific to your custom application. Related configuration includes User Administration > Roles for managing which roles can see specific applications and modules.

See navigator configuration in action by switching between user roles at System Security > Impersonate User to test how different role assignments affect menu visibility. Check navigator filter behavior and search indexing at System Properties > UI Properties where properties like glide.ui.filter_navigator_by_description control search functionality. The key difference between scoped and global applications is that scoped applications automatically create application records when you publish them, while global applications require manual creation of both application and module records with proper scope settings.

How It Works Step by Step

The Application Navigator operates through a real-time evaluation system that queries application and module records against the current user's role assignments during each session initialization and navigation refresh. When a user logs in or changes context, ServiceNow builds the navigation menu by first retrieving all application records where the user has matching roles, then fetching associated module records that also pass role validation. The system caches this navigation structure in the user's session but re-evaluates role conditions whenever roles change or when navigating between different application scopes.

Role inheritance plays a crucial part in navigator visibility, where users inherit navigation access from parent roles and role groups, while application-specific roles can override or extend base platform access. The navigator also respects table-level ACL restrictions, meaning users might see a module in the navigation but receive access denied errors when clicking if they lack proper table permissions. Module ordering within applications follows the order field value, while application ordering can be controlled through application menu categories and their associated ordering rules.

The Execution Order

1. User authentication triggers navigation menu construction by querying the sys_app_application table for applications where current user roles match the application's roles field or where the application has no role restrictions.
2. For each accessible application, ServiceNow queries sys_app_module records where the application field matches the application record and applies role filtering again at the module level.
3. Module records are evaluated for active status (active=true) and sorted by order field values, with duplicate order numbers sorted alphabetically by title.
4. The system builds the navigation tree structure, grouping modules under their parent applications and applying any category-based organization defined in sys_app_category.
5. Navigation structure gets cached in user session data with cache invalidation triggered by role changes, application updates, or explicit cache clearing.
6. When users click modules, the platform reads the module's link_type and constructs the appropriate URL using table, query, or application field values before final ACL validation at the target resource.

// Query to find all accessible applications for current user
var appGR = new GlideRecord('sys_app_application');
appGR.addQuery('active', true);
appGR.addQuery('roles', 'CONTAINS', gs.getUser().getRoles().toString());
appGR.orderBy('title');
appGR.query();

// For each application, get accessible modules
while (appGR.next()) {
    var modGR = new GlideRecord('sys_app_module');
    modGR.addQuery('application', appGR.getUniqueValue());
    modGR.addQuery('active', true);
    modGR.addQuery('roles', 'CONTAINS', gs.getUser().getRoles().toString());
    modGR.orderBy('order');
    modGR.orderBy('title');
    modGR.query();
    gs.info('Application: ' + appGR.getDisplayValue('title') + ' has ' + modGR.getRowCount() + ' accessible modules');
}

Real-World Scenarios

Creating Custom Application with Role-Restricted Access

Your organization needs a custom Asset Tracking application that only facilities managers and IT asset coordinators can access, with separate modules for different asset types. The business requires strict role segregation where general users cannot see asset management functionality in their navigation menus.

// Create the application record
var appGR = new GlideRecord('sys_app_application');
appGR.initialize();
appGR.setValue('title', 'Asset Tracking');
appGR.setValue('hint', 'Manage organizational assets and inventory');
appGR.setValue('roles', 'asset_manager,facilities_admin');
appGR.setValue('order', 100);
appGR.setValue('active', true);
var appSysId = appGR.insert();

// Create modules for different asset types
var moduleTypes = [
    {title: 'All Assets', table: 'alm_asset', link_type: 'LIST'},
    {title: 'Create Asset', table: 'alm_asset', link_type: 'NEW'},
    {title: 'Hardware Assets', table: 'alm_asset', link_type: 'LIST', query: 'install_status!=7^category=Hardware'},
    {title: 'Software Assets', table: 'alm_asset', link_type: 'LIST', query: 'category=Software'}
];

moduleTypes.forEach(function(module, index) {
    var modGR = new GlideRecord('sys_app_module');
    modGR.initialize();
    modGR.setValue('title', module.title);
    modGR.setValue('application', appSysId);
    modGR.setValue('name', module.table);
    modGR.setValue('link_type', module.link_type);
    modGR.setValue('table', module.table);
    if (module.query) modGR.setValue('query', module.query);
    modGR.setValue('roles', 'asset_manager,facilities_admin');
    modGR.setValue('order', (index + 1) * 100);
    modGR.setValue('active', true);
    modGR.insert();
});

Watch for role inheritance issues where users might have broader roles like admin that automatically grant access despite not being explicitly listed in module roles. Test navigation visibility by impersonating users with only the specific roles assigned, and verify that ACL rules on the underlying tables match the navigator role restrictions to prevent access denied errors.

Organizing Complex Application with Categories and Separators

Your ITSM implementation has grown to include 40+ modules under the Incident application, making navigation unwieldy for agents who need quick access to specific incident queues and reporting tools. Business users want logical groupings that separate day-to-day operations from administrative functions and reporting.

1. Navigate to System Definition > Application Menus and open the Incident application record
2. Create separator modules by setting link_type to SEPARATOR with titles like 'Daily Operations' and 'Administration'
3. Reorder existing modules using order field values: Daily Operations (100), Create Incident (110), My Incidents (120), separator (200), Administration (210), Incident Rules (220)
4. Apply role-based visibility where operational modules show to itil role but administrative modules require admin or incident_admin roles

Separator modules don't display in Next Experience the same way they do in Classic UI, appearing as subtle dividers rather than bold section headers. Consider using application categories through sys_app_category for more robust grouping that works consistently across both interfaces. Test the ordering with different user roles since separators only show when users can see modules both above and below them in the navigation sequence.

Implementing Dynamic Module Queries for Personalized Navigation

Your service desk needs personalized incident queues where agents automatically see modules for incidents assigned to their team, managed by their group, or in their location, without manual filter configuration. The navigation should dynamically update when user assignments change without requiring administrator intervention.

// Create modules with dynamic queries using session variables

// Module 1: My Assigned Incidents
var modGR = new GlideRecord('sys_app_module');
modGR.initialize();
modGR.setValue('title', 'My Assigned Incidents');
modGR.setValue('application', incident_app_sys_id);
modGR.setValue('link_type', 'LIST');
modGR.setValue('table', 'incident');
modGR.setValue('query', 'assigned_to=javascript:gs.getUserID()');
modGR.setValue('roles', 'itil');
modGR.setValue('order', 150);
modGR.setValue('active', true);
modGR.insert();

// Module 2: My Team's Incidents  
var modGR2 = new GlideRecord('sys_app_module');
modGR2.initialize();
modGR2.setValue('title', 'My Team Incidents');
modGR2.setValue('application', incident_app_sys_id);
modGR2.setValue('link_type', 'LIST');
modGR2.setValue('table', 'incident');
modGR2.setValue('query', 'assignment_group=javascript:gs.getUser().getManagerID()');
modGR2.setValue('roles', 'itil');
modGR2.setValue('order', 160);
modGR2.setValue('active', true);
modGR2.insert();

// Module 3: Location-Based Incidents
var modGR3 = new GlideRecord('sys_app_module');
modGR3.initialize();
modGR3.setValue('title', 'My Location Incidents');
modGR3.setValue('application', incident_app_sys_id);
modGR3.setValue('link_type', 'LIST');
modGR3.setValue('table', 'incident');
modGR3.setValue('query', 'location=javascript:gs.getUser().getLocation()');
modGR3.setValue('roles', 'itil');
modGR3.setValue('order', 170);
modGR3.setValue('active', true);
modGR3.insert();

Dynamic queries work well for user-specific data but fail when users don't have the expected attributes populated (like missing manager or location assignments). Include fallback logic in your queries or create conditional modules that only appear when users have the required attributes. Monitor module load times through System Diagnostics > Stats since complex javascript queries can slow navigation performance significantly.

The Classic Mistake

The worst offender is creating modules named Users in multiple custom applications. When an admin searches for users in the Filter Navigator, they get five different results: System Security > Users, Employee Center > Users, and three custom application modules all called Users. Even worse, the modules show identical icons and similar descriptions. Users click the wrong one repeatedly, then complain that ServiceNow navigation is "broken" because they're looking at sys_user records when they expected custom employee records.

This happens because the Filter Navigator searches the title field in sys_app_module records across all applications visible to the user. ServiceNow doesn't namespace module names by application in search results—it just returns everything that matches. The user sees multiple identical titles with minimal context about which application owns each module. They guess wrong, waste time, and lose confidence in the navigation system.

// GOOD: Descriptive, unique module names

// HR Application modules:
"HR Employee Records"     // Not just "Users" 
"HR Org Chart"           // Not just "Organization"
"HR Onboarding Tasks"    // Not just "Tasks"

// Facilities Application modules:
"Facility Access Cards"  // Not just "Cards"
"Space Assignments"      // Not just "Assignments" 
"Building Maintenance"   // Not just "Maintenance"

// Custom IT App modules:
"IT Asset Inventory"     // Not just "Assets"
"Software Licenses"      // Not just "Licenses"
"IT Service Requests"    // Not just "Requests"

When to Use This vs Alternatives

Use the Application Navigator for structured, role-based access to forms, lists, and reports that users access regularly as part of their workflow. This is the primary navigation method for users who need consistent access to the same set of ServiceNow functionality day-to-day. The Navigator excels when you have defined user roles that map to specific applications and modules.

When Application Navigator is the Right Choice

Choose Application Navigator when users need organized access to multiple related tables and functions within a business domain. It's superior to workspace tabs or dashboard buttons for comprehensive administrative functions because it provides hierarchical organization and contextual grouping. The Navigator also handles role-based security better than custom UI pages, automatically hiding modules based on ACL rules and role assignments.

When to Use Workspaces Instead

Use Agent Workspace or Employee Center workspaces when users focus on individual record processing or case resolution rather than navigating between different table types. Workspaces excel for single-purpose roles like incident handlers or request fulfillers who spend most of their time in forms and related records. The contextual side panels and embedded lists in workspaces are more efficient than jumping between Navigator modules for record-centric work.

When You Need Both Together

Configure both Application Navigator modules and workspace experiences for roles that switch between administrative tasks and operational work. For example, IT managers need Navigator modules for user administration, reporting, and configuration, but also need ITSM workspace access for escalated incidents. Use the Navigator for setup and oversight functions, workspaces for daily operational tasks, and ensure both respect the same role-based access controls.

Platform Interactions & Side Effects

• ACL rules automatically filter visible modules based on sys_app_module.roles and table-level read access—modules disappear silently when users lack proper roles
• Module conditions are evaluated on every page load and cached per user session in user_preference table, causing performance issues with complex scripted conditions
• Update sets capture sys_app_module and sys_app_application changes but don't handle module ordering conflicts between instances
• Module filter preferences are stored in sys_user_preference.name='navigator.expanded' and can become corrupted with invalid JSON, breaking navigation
• Business rules firing on sys_app_module table can break module creation workflows and cause infinite loops during Application Creator processes
• Global search indexing includes module titles from sys_app_module.title, causing navigation modules to appear in general search results unexpectedly
• Module hint fields support HTML but are not sanitized, creating XSS vulnerabilities when populated from user input or external sources
• Database views defined in module filter field override user's personal list filters and can't be modified by end users, causing confusion
• Module analytics track clicks in syslog_transaction with type='security' when glide.ui.security.track_navigation_access=true
• Related list modules create hidden sys_ui_list records that conflict with manual list configurations on the same table and view

Debugging and Troubleshooting

When modules don't appear in the Application Navigator, users see empty applications or missing menu items without error messages. Admins typically discover this when users report they "can't find" functionality that was working previously. The most common symptoms are modules that appear for admin users but not for regular users, modules that disappear after role changes, or Filter Navigator searches returning no results for known module names. Check System Log > All for ACL denials with source security_acl and look for entries mentioning the module's target table. Module condition failures generate JavaScript errors in the browser console but not in ServiceNow logs, so check browser developer tools for condition script errors.

Module ordering and display issues manifest as applications appearing in wrong positions or modules showing in incorrect sequence within applications. Navigate to System Definition > Application Menus and check order field values for overlapping numbers. Use Background Scripts to query module conditions that may be returning inconsistent results. Filter Navigator problems often stem from corrupted user preferences—clear them by deleting records from sys_user_preference where name starts with navigator for the affected user.

Diagnostic Checklist:

• Impersonate the affected user and verify role assignments in User Administration > Users role tabs
• Check module active checkbox and condition script in sys_app_module table
• Test module URL directly by copying link_type value and browsing to the target page
• Verify table ACL read permissions using Access Control Debug with glide.security.ui.acl.debug=true
• Clear browser cache and user session, then logout/login to refresh Navigator cache
• Check application active status and user_role field in sys_app_application record
• Run Navigator rebuild using gs.clearNavigatorCache() in Background Scripts for persistent issues

Quick Reference

• Module order field accepts decimals—use 100, 110, 120 for easy insertion rather than 1, 2, 3
• Filter Navigator searches module title and hint fields but ignores application names—add keywords to hint for better discoverability
• Maximum of 50 modules per application before Navigator performance degrades noticeably in Classic UI
• Module condition scripts can't access current object—use gs.getUser() and gs.hasRole() instead
• Separator modules with link_type='SEPARATOR' don't display in Next Experience but still affect module ordering
• Module icons support custom images but require 16x16 pixel PNG files uploaded to sys_attachment table with specific naming
• URL-type modules with link_type='DIRECT' don't inherit user session context—external URLs won't have ServiceNow authentication
• Application scope affects module creation but not visibility—Global modules appear in scoped applications if roles match
• Module window_name field controls browser tab targeting—identical values force single tab reuse across modules
• Deep-linking to modules requires $navpage.do URL format with module sys_id parameter for bookmarking specific Navigator locations