ServiceNow Application Menus: What They Are & How They Work

By /






What are Application Menus in ServiceNow: Your Ultimate Guide to Navigation and Customization



What are Application Menus in ServiceNow: Your Ultimate Guide to Navigation and Customization

Ever found yourself staring at a new software system, feeling a bit lost like a tourist without a map? You know there’s a world of functionality inside, but how do you get to where you need to go? In the vast and powerful landscape of ServiceNow, the answer lies in its unsung heroes: Application Menus and their trusty sidekicks, Modules. These aren’t just mere links; they are the very scaffolding that guides users through their daily tasks, making complex processes feel intuitive and accessible.

Whether you’re an end-user trying to report an incident, an IT administrator configuring a new service, or a developer building custom applications, understanding Application Menus is fundamental. They dictate what you see, what you can do, and how efficiently you can navigate the platform. In this detailed guide, we’re going to pull back the curtain on Application Menus in ServiceNow. We’ll explore what they are, why they’re absolutely crucial for a smooth user experience, how to wield their power for customization, tackle common issues, and even prepare you for those tricky interview questions.

Get ready to transform from a lost tourist to a seasoned ServiceNow explorer!

The Grand Tour Guide: What Exactly Are Application Menus?

Let’s start with the basics, drawing directly from the core definition: “To make the forms and lists available to end users, we can create a module in ServiceNow using application menus.”

Think of ServiceNow as a massive, multi-story building – a modern skyscraper with countless offices, departments, and specialized functions. Without clear signage, directories, or a logical layout, navigating it would be a nightmare. This is where Application Menus come in. They are the primary navigational categories displayed in the left-hand Navigator panel of your ServiceNow instance. Each Application Menu acts like a major department sign, grouping related functionalities together.

For example, you’ll commonly see Application Menus like “Incident,” “Change,” “HR,” “Service Catalog,” or “Self-Service.” Each of these is a distinct Application Menu, signaling a particular area of the platform’s functionality.

Introducing the Modules: The Specific Destinations

Within each Application Menu, you’ll find a series of individual links. These are called Modules. If the Application Menu is the department sign, then Modules are the specific room numbers or office names within that department.

Under the “Incident” Application Menu, for instance, you might find Modules like:

  • Create New: A link to open a blank Incident form.
  • Open: A list of all currently active incidents.
  • My Incidents: A list of incidents assigned to or created by the logged-in user.
  • All: A comprehensive list of every incident in the system.

Each Module serves as a direct gateway to a specific form, list, report, or even an external URL. They are the actionable items that users click to perform their tasks.

The Hierarchy in a Nutshell:

  1. Application Menu: The top-level category (e.g., “Incident”).
  2. Module: The specific action or link within that category (e.g., “Create New”).

Together, Application Menus and Modules form the backbone of ServiceNow’s navigation, guiding users logically and efficiently through what can be an incredibly complex and feature-rich platform. They make the platform accessible, ensure that users can quickly find what they need, and crucially, they can be tailored to show only what’s relevant to a specific user’s role and responsibilities.

Why Application Menus Are More Than Just Links: The “Why It Matters”

You might think, “Okay, so they’re just navigation links, big deal.” But in ServiceNow, these menus and modules are profoundly impactful. Their design and configuration directly influence user experience, security, and the overall efficiency of your organization. Here’s why they are absolutely critical:

1. User Experience (UX) Central: The Guiding Hand

Imagine logging into ServiceNow and seeing hundreds of links jumbled together. It would be overwhelming, frustrating, and likely lead to errors. Application Menus provide structure and order. They guide users intuitively, allowing them to quickly identify the relevant section (e.g., “HR” for HR-related tasks, “ITSM” for IT tasks) and then the specific action they need to take. A well-designed navigation significantly reduces cognitive load and improves user satisfaction.

2. Efficiency and Productivity: Time is Money

When users can instantly find the “Create New Incident” module or the “Open Changes” list, they save precious seconds. Multiply that by hundreds or thousands of users performing tasks multiple times a day, and the efficiency gains become enormous. Application Menus streamline workflows by providing direct access points, reducing clicks and search time.

3. Role-Based Access Control (RBAC): Showing Only What’s Relevant

This is arguably one of the most powerful aspects of Application Menus and Modules. ServiceNow is a platform where different users have different responsibilities and, consequently, different access needs. An HR manager doesn’t need to see IT incident queues, and an IT technician shouldn’t have access to sensitive HR profiles.

Application Menus and Modules can be configured with specific roles. If a user doesn’t possess the required role for an Application Menu or Module, they simply won’t see it. This keeps the navigation clean and tailored, but more importantly, it’s a fundamental security measure, ensuring users only interact with the parts of the platform they are authorized to use. For example, an ITIL user will see the “Incident” and “Change” menus, but a self-service user (with the ‘sn_request_read’ role, for instance) might only see “Self-Service” and “Service Catalog.”

4. Platform Customization & Personalization: Tailoring Your Instance

ServiceNow is rarely used out-of-the-box. Organizations customize it extensively to fit their unique processes. Application Menus and Modules are primary vehicles for this customization. You can:

  • Create new Application Menus for custom applications.
  • Add new Modules to existing menus to provide access to custom forms, lists, or reports.
  • Modify existing Modules to change their target, visibility, or order.

This allows administrators to tailor the platform’s navigation precisely to the needs of their business and its users.

5. Governance & Standardization: Consistency Across the Board

In large organizations, consistency is key. Application Menus help enforce standardized access patterns. By centrally managing these navigation elements, administrators ensure that all users with a specific role have the same, consistent access points to perform their duties. This reduces confusion, simplifies training, and helps maintain order within the platform.

6. Scalability: Growing with Your Business

As your organization grows and adopts more ServiceNow applications (ITSM, HRSD, CSM, FSM, GRC, etc.), the navigation structure needs to scale. Well-designed Application Menus allow new functionalities to be integrated seamlessly without overwhelming users or disrupting existing workflows. You can easily add new application menus and modules for new departments or services, keeping everything organized.

In essence, Application Menus and Modules transform ServiceNow from a mere collection of tables and scripts into a coherent, user-friendly, and secure operational platform.

Under the Hood: Dissecting an Application Menu and its Modules

Now that we understand their importance, let’s get our hands dirty and see how Application Menus and Modules are actually constructed and configured within ServiceNow. This is where you, as an administrator or developer, gain the power to shape the user experience.

Accessing and Managing Application Menus

You can find the list of all Application Menus by navigating to:
System Definition > Application Menus

Clicking on any Application Menu record will open its form, where you can configure its properties:

  • Title: The display name of the Application Menu (e.g., “Incident”).
  • Order: A numerical value that determines its position in the left-hand navigator. Lower numbers appear higher up. (e.g., Incident might be 100, Change 200).
  • Active: A checkbox to enable or disable the entire Application Menu. If unchecked, it won’t appear for anyone.
  • Roles: This is crucial! Only users with at least one of the specified roles will see this Application Menu. If left blank, it’s visible to everyone (which is rarely desired for sensitive applications).
  • Hint: A tooltip that appears when a user hovers over the Application Menu title.
  • Application: The scope of the application menu (e.g., “Global,” “ITSM,” “Human Resources: Core”). This is important for managing customizations within different application scopes.

Delving into Modules: The Building Blocks

Modules are managed from within the Application Menu record (via a related list at the bottom) or directly via:
System Definition > Modules

When you create or modify a Module, you’ll encounter a rich set of configuration options:

  • Title: The display name of the Module (e.g., “Create New”).
  • Application Menu: A reference field linking the Module to its parent Application Menu.
  • Order: Similar to Application Menus, this number determines the Module’s position within its parent Application Menu. Lower numbers appear higher.
  • Active: A checkbox to enable or disable the Module.
  • Roles: Just like Application Menus, this controls visibility. Only users with one of the specified roles will see this Module. This provides granular control even if they can see the parent Application Menu.
  • Visibility: Determines if the module is visible on the platform UI, Mobile, Service Portal, or other interfaces.
  • Override application menu roles: If checked, the module’s roles will override the parent Application Menu’s roles. This can be useful for making a specific module more widely (or narrowly) available than its parent.
  • Hint: A tooltip for the Module.
  • Application: The application scope of the module.

The Power of Link Types: What a Module Can Do

The most defining characteristic of a Module is its Link Type. This field dictates what happens when a user clicks the Module. Understanding these is key to creating powerful and effective navigation. Here are the most common and important ones:

  1. List of Records:
    • Purpose: Displays a list of records from a specific table, often filtered by a query.
    • Configuration:
      • Table: The table to display (e.g., incident, change_request).
      • Arguments: A URL query string to filter the list (e.g., active=true^ORDERBYDESCnumber for active incidents sorted by number).
    • Real-world Example: The “Open Incidents” module under the “Incident” Application Menu, showing all active incident records.
  2. New Record:
    • Purpose: Opens a blank form for creating a new record in a specified table.
    • Configuration:
      • Table: The table for which to create a new record (e.g., incident, sc_request).
      • Arguments: Pre-populate fields on the new form (e.g., assigned_to=javascript:gs.getUserID() to assign to the current user).
    • Real-world Example: The “Create New” module under “Incident” or “Change.”
  3. URL (from Arguments):
    • Purpose: Directs the user to an external URL or a specific internal ServiceNow page that isn’t a standard form/list.
    • Configuration:
      • Arguments: The full URL (e.g., https://www.google.com or https://yourinstance.service-now.com/sp to go to the Service Portal homepage).
    • Real-world Example: A module linking to your company’s external knowledge base, or directly to a specific Service Portal page.
  4. Script (from Arguments):
    • Purpose: Executes a server-side JavaScript script when clicked. This is for advanced use cases where you need custom logic before redirecting or performing an action.
    • Configuration:
      • Arguments: The script to execute (e.g., a function call or a complex logic). The script must return a URL to redirect to.
    • Real-world Example: A module that performs a specific calculation, updates several records, and then redirects to a confirmation page.
  5. Separator:
    • Purpose: Creates a visual line to group Modules within an Application Menu, enhancing readability.
    • Configuration: No specific arguments, just a Title (often blank or a series of hyphens) and Order.
    • Real-world Example: Separating “Create New” from “Open” and “Closed” lists in the Incident menu.
  6. Report:
    • Purpose: Directs the user to a specific report.
    • Configuration:
      • Arguments: The sys_id of the report (e.g., sys_report_template.do?sys_id=SOME_REPORT_SYS_ID).
    • Real-world Example: A “Monthly Incident Trends” module under a “Reporting” Application Menu.
  7. Homepage:
    • Purpose: Directs the user to a specific ServiceNow homepage or dashboard.
    • Configuration:
      • Arguments: The sys_id of the homepage (e.g., sys_analytics_dashboard.do?sys_id=SOME_DASHBOARD_SYS_ID).
    • Real-world Example: An “ITSM Dashboard” module.

By mastering these fields and link types, you gain precise control over how users interact with ServiceNow, ensuring a tailored and highly efficient experience for everyone.

Real-World Scenarios: Application Menus in Action

Let’s bring this to life with some practical examples of how Application Menus and Modules are leveraged across different ServiceNow applications.

1. IT Service Management (ITSM): The Everyday Core

  • Application Menu: Incident
    • Module: Create New (Link Type: New Record, Table: incident) – For quickly logging a new issue.
    • Module: Open (Link Type: List of Records, Table: incident, Arguments: active=true) – To see all currently active incidents needing attention.
    • Module: My Incidents (Link Type: List of Records, Table: incident, Arguments: active=true^assigned_to=javascript:gs.getUserID()) – Personalized list for IT technicians.
  • Application Menu: Change
    • Module: Create New (Link Type: New Record, Table: change_request) – Initiate a new change.
    • Module: All Changes (Link Type: List of Records, Table: change_request) – Overview of all changes.
  • Application Menu: Service Catalog
    • Module: Catalog (Link Type: URL, Arguments: /sp?id=sc_home or /nav_to.do?uri=%2F$catalog.do) – Direct link to the Service Portal catalog for users to request services and items.
    • Module: My Requests (Link Type: List of Records, Table: sc_request, Arguments: requested_for=javascript:gs.getUserID()) – Users can track their submitted requests.

2. HR Service Delivery (HRSD): Employee-Centric Navigation

  • Application Menu: HR Profile
    • Module: My Profile (Link Type: New Record, Table: sn_hr_core_profile, Arguments: sys_id=javascript:new sn_hr_core.HRProfile().getHRProfileSysId(gs.getUserID())) – Employees can view/update their own HR profile.
    • Module: All Profiles (Link Type: List of Records, Table: sn_hr_core_profile) – For HR managers to view all employee profiles (visible only to users with appropriate HR roles).
  • Application Menu: HR Tasks
    • Module: My HR Tasks (Link Type: List of Records, Table: sn_hr_core_task, Arguments: assigned_to=javascript:gs.getUserID()^ORopened_by=javascript:gs.getUserID()) – For HR agents to manage their assigned tasks.

3. Customer Service Management (CSM): External User Focus

  • Application Menu: Customer Service
    • Module: Create New Case (Link Type: New Record, Table: sn_customerservice_case) – For agents to log customer issues.
    • Module: My Cases (Link Type: List of Records, Table: sn_customerservice_case, Arguments: assigned_to=javascript:gs.getUserID()) – Agents managing their caseload.

4. Custom Applications: Tailored Solutions

Let’s say your company builds a custom “Facilities Management” application. You would create a new Application Menu called “Facilities Management” and populate it with modules like:

  • Module: Submit Work Order (Link Type: New Record, Table: u_facilities_work_order – your custom table)
  • Module: View My Requests (Link Type: List of Records, Table: u_facilities_work_order, Arguments: requested_for=javascript:gs.getUserID())
  • Module: Building Inventories (Link Type: List of Records, Table: u_building_inventory)

These examples highlight how Application Menus and Modules are not just theoretical concepts but practical tools that directly shape how users interact with and utilize the ServiceNow platform for their specific job functions.

Best Practices for Designing and Managing Application Menus

Like any powerful tool, Application Menus require thoughtful design and ongoing management to be truly effective. Here are some best practices to keep your ServiceNow navigation clean, intuitive, and secure:

1. Keep it Simple and Intuitive

Avoid clutter. Too many Application Menus or too many Modules within a menu can be overwhelming. Strive for clarity. Users should be able to guess where to find what they need.

2. Logical Grouping

Group related Modules under a sensible Application Menu. For instance, all incident-related lists and forms belong under “Incident.” Use separators within menus to logically segment lists from creation forms or different types of reports.

3. Consistent Naming Conventions

Use clear, consistent, and concise titles for both Application Menus and Modules. For example, stick to “Create New” or “New [Item]” consistently, rather than mixing “New Incident” with “Log a Change.” Consistency reduces confusion.

4. Leverage Roles Wisely (and Precisely)

This is paramount for security and user experience. Assign roles at both the Application Menu and Module level. The principle of “least privilege” applies here: users should only see and access what they absolutely need to perform their job functions. Over-assigning roles can lead to security vulnerabilities and an unnecessarily cluttered navigator.

  • Application Menu Roles: Controls broad visibility (e.g., only ITIL users see the “Incident” menu).
  • Module Roles: Controls granular visibility within an application (e.g., only ‘problem_manager’ sees the “Problem Analysis Report” module under the “Problem” menu).

5. Test Thoroughly with Different Personas

Always test your Application Menu and Module configurations with users representing different roles (e.g., ITIL user, HR user, self-service user, admin). What looks right to an admin (who sees everything) might be completely different for a regular user.

6. Regular Review and Maintenance

Over time, modules can become obsolete, applications change, or new requirements emerge. Periodically review your Application Menus and Modules. Deactivate or delete unused ones to keep the navigator tidy and performant. This is especially important during major upgrades or after significant process changes.

7. Consider User Personas and Workflows

Design your navigation not just based on tables, but on how your actual users work. What are their most frequent tasks? What information do they need to access quickly? Prioritize those links and make them prominent (using the ‘Order’ field).

8. Use “Order” for Strategic Placement

Strategically use the ‘Order’ field (e.g., 100, 200, 300) to place the most frequently accessed Application Menus and Modules at the top of the navigator. Leave gaps (e.g., 100, 150, 200) to allow for insertion of new items later without re-ordering everything.

By following these best practices, you can ensure that your ServiceNow navigation remains a valuable asset, not a source of frustration.

Troubleshooting Common Application Menu Headaches

Even with the best planning, things can go wrong. Here’s a look at common issues you might encounter with Application Menus and Modules, and how to troubleshoot them:

1. “Why Can’t I See It?” – The Invisible Menu/Module

This is by far the most common issue. A user reports they can’t see an Application Menu or Module they expect to.

  • Check #1: Roles!
    • Go to the Application Menu record. Check the ‘Roles’ field. Does the user have *at least one* of the roles listed?
    • Go to the Module record. Check the ‘Roles’ field. Does the user have *at least one* of the roles listed?
    • Remember: If the parent Application Menu has roles, and the Module has roles, the user needs to satisfy both (unless ‘Override application menu roles’ is checked on the module). The most restrictive setting wins.
  • Check #2: Active Flag
    • Is the Application Menu ‘Active’?
    • Is the Module ‘Active’? If either is unchecked, it won’t be visible.
  • Check #3: Application Scope (for custom items)
    • If it’s a custom Application Menu or Module, ensure the user has the necessary roles for the application scope it belongs to, or that the application scope allows global visibility.
  • Check #4: User Personalization
    • Users can sometimes remove items from their own navigator. Ask the user to click the gear icon (Settings) and then “Reset to default” under “Navigator.”

2. “It’s in the Wrong Order!” – Misplaced Navigation Items

An Application Menu or Module isn’t appearing where you expect it in the list.

  • Check the ‘Order’ Field:
    • For Application Menus, review the ‘Order’ field values. Lower numbers appear higher. If you want “Change” above “Incident,” “Change” needs a lower order number.
    • For Modules, review the ‘Order’ field within the *same parent Application Menu*. Again, lower numbers appear higher.
  • Conflicting Order Values: If two items have the same order value, their display order might be inconsistent or default to alphabetical. Always use unique order values.

3. “Clicking Does Nothing / Wrong Page!” – Incorrect Target

A user clicks a Module, but it either does nothing, shows an error, or takes them to the wrong page.

  • Check ‘Link Type’ and ‘Arguments’:
    • List of Records / New Record: Ensure the ‘Table’ name is correct and the ‘Arguments’ (if any) are valid query strings. A typo in the table name is a common culprit.
    • URL: Verify the URL in ‘Arguments’ is correct and accessible.
    • Script: Debug the script in ‘Arguments’. Ensure it correctly returns a URL for redirection and doesn’t have syntax errors.
    • Report / Homepage: Confirm the sys_id in the ‘Arguments’ field refers to an existing and accessible report or homepage.
  • Access to Target: Even if the Module is visible, the user might not have access to the underlying form, list, or report due to ACLs (Access Control Lists). The Module might appear, but clicking it leads to a “Security Constraint” message.

4. “My Custom Item Disappeared After an Upgrade!”

While less common for Application Menus/Modules themselves, if they are part of a custom application or were modified in a way that conflicts with a ServiceNow upgrade, they *could* be affected.

  • Review Upgrade Skips: After an upgrade, always review the ‘Upgrade History’ and ‘Skipped Changes’ module (/sys_upgrade_history_list.do). This will show if any of your customizations were skipped or modified due to conflicts with the new version.
  • Test in Sub-Production First: Always perform upgrades in your development or test environments first, thoroughly testing all custom navigations.

Troubleshooting Application Menus and Modules usually boils down to systematically checking the ‘Active’ flag, ‘Roles’ field, ‘Order’ field, and the ‘Link Type’/’Arguments’ configuration. A little patience and methodical checking will usually reveal the problem.

Nailing the Interview: Application Menus in the Spotlight

If you’re interviewing for a ServiceNow administrator, developer, or even a power user role, expect questions about Application Menus and Modules. Why? Because they are fundamental. Interviewers use these questions to gauge your practical understanding of the platform’s architecture, user experience principles, and security mechanisms.

Why Interviewers Ask About Them:

  • Fundamental Knowledge: It confirms you understand basic ServiceNow navigation and configuration.
  • UX Awareness: Demonstrates your appreciation for good user experience and how to build it.
  • Security Acumen: Shows you understand how to control access and secure the platform.
  • Practical Application: Tests your ability to apply concepts (e.g., creating custom modules).
  • Problem-Solving Skills: Discussing troubleshooting scenarios highlights your analytical abilities.

Common Interview Questions and How to Answer Them Effectively:

1. “What are Application Menus and Modules in ServiceNow? Explain their relationship.”

  • Answer Strategy: Start with a clear definition, use an analogy, and explain the hierarchy.
    • “Application Menus are the top-level navigational categories in the left-hand navigator, like ‘Incident’ or ‘HR.’ They logically group related functionalities.”
    • “Modules are the specific links or actions found within an Application Menu, such as ‘Create New Incident’ or ‘My Open Changes.’ They are the clickable items that take you to a form, list, or report.”
    • “Their relationship is hierarchical: an Application Menu is a container for one or more Modules. You can’t have a Module without a parent Application Menu.”
    • Analogy (optional but helpful): “Think of an Application Menu as a main section in a library (e.g., ‘Fiction’), and Modules as the specific books or subsections within it (e.g., ‘Fantasy,’ ‘Sci-Fi,’ ‘Mystery novels’).”

2. “How do you control who sees an Application Menu or a specific Module?”

  • Answer Strategy: Focus on the ‘Roles’ field and explain the logic.
    • “Access is primarily controlled using the ‘Roles’ field on both the Application Menu and Module records.”
    • “If roles are specified, a user must possess at least one of those roles to see the item. If the ‘Roles’ field is left blank, it’s generally visible to everyone.”
    • “For a Module to be visible, the user must have the required roles for both the parent Application Menu AND the Module itself (unless the Module’s ‘Override application menu roles’ is checked).”
    • “This ensures granular control over visibility, adhering to the principle of least privilege, and enhancing security.”

3. “Can you create a custom Module? Walk me through the steps and give an example.”

  • Answer Strategy: Describe the process and include key fields and a practical example.
    • “Yes, absolutely. You’d typically navigate to System Definition > Modules or go to the parent Application Menu record and use the Modules related list.”
    • “Steps would include: 1. Click ‘New.’ 2. Provide a ‘Title’ (e.g., ‘All My Custom Requests’). 3. Link it to an ‘Application Menu’ (either an existing one or a new custom one). 4. Define the ‘Order’ for its placement. 5. Crucially, select the ‘Link Type’ (e.g., ‘List of Records’ for a list of my custom requests). 6. Specify the ‘Table’ (e.g., u_my_custom_table) and ‘Arguments’ (e.g., active=true^requested_by=javascript:gs.getUserID()). 7. Assign ‘Roles’ to control visibility. 8. Ensure ‘Active’ is checked.”
    • “This allows you to expose custom forms, lists, or even external links through the navigator.”

4. “Explain the purpose of the ‘Order’ field for Application Menus and Modules.”

  • Answer Strategy: Focus on visual placement and best practices for using it.
    • “The ‘Order’ field is a numerical value that determines the display sequence of Application Menus in the left navigator, and Modules within an Application Menu.”
    • “Lower numbers appear higher on the list. For instance, an Application Menu with an order of 100 will appear above one with 200.”
    • “It’s best practice to leave gaps between order numbers (e.g., 100, 200, 300 instead of 1, 2, 3) to allow for easy insertion of new items later without having to re-number everything.”

5. “Name a few different ‘Link Types’ for Modules and when you would use them.”

  • Answer Strategy: List 2-3 common types and provide practical use cases.
    • “List of Records: Used to display a filtered list of records from a table, like ‘Open Incidents’ or ‘All Users’.”
    • “New Record: Used to open a blank form to create a new record, such as ‘Create New Change Request’.”
    • “URL (from Arguments): Useful for linking to external websites or specific Service Portal pages, like a ‘Company Wiki’ or the ‘Service Portal Home’.”
    • “Separator: A simple line to visually group related modules within an application menu for better organization.”
    • (Bonus points for mentioning Script, Report, or Homepage link types if you have time.)

By preparing these answers and speaking confidently about these foundational components, you’ll demonstrate a solid grasp of ServiceNow administration and development.

Conclusion: The Unsung Heroes of Navigation

Application Menus and Modules are far more than just lists of links. They are the meticulously crafted navigational tools that transform the vast, intricate ServiceNow platform into an accessible, efficient, and secure environment for every user. From guiding a new employee through their HR onboarding tasks to enabling an IT pro to rapidly resolve a critical incident, their impact is pervasive and profound.

A well-designed navigation structure, powered by thoughtfully configured Application Menus and Modules, is the bedrock of a positive ServiceNow user experience. It boosts productivity, reinforces security through role-based visibility, and provides the flexibility for organizations to tailor the platform to their precise operational needs. For anyone working with ServiceNow, whether as an end-user, administrator, or developer, understanding these components isn’t just helpful – it’s essential.

So, the next time you log into your ServiceNow instance, take a moment to appreciate those quiet powerhouses on the left. They are the unsung heroes, diligently ensuring that you always know where you are, and more importantly, where you need to go.

Now, go forth and explore your instance with newfound clarity!


Scroll to Top