Foundations · Lesson 1.2

Next Experience, experiences and app shells

  • Beginner
  • 15 min read
  • Tested on Australia
  • Updated 18 Oct 2026
  • Next Experience
  • UI Builder
  • Workspaces

What Next Experience is

For many years, ServiceNow looked the same for everyone: a navigator on the left listing every module, and forms and lists on the right. That interface is called UI16 (classic interface)The older ServiceNow interface, with the application navigator on the left, used before Next Experience.Learn more , and many people simply call it the classic UI.

In the San Diego release, ServiceNow introduced Next Experience, a complete redesign of how the platform looks and how you move around it. It brought a new header with All, Favorites, History and Workspaces menus, a single search box for the whole platform, themes including a dark mode, and a modern design used across every new screen. Internally, the project was called Polaris, which is why you will still see that name in some system properties.

Next Experience did not throw the classic UI away. Your existing forms, lists and modules still work, and they open inside the new interface. What changed is the frame around them, and the arrival of experiences built with UI BuilderServiceNow's drag-and-drop tool for building Next Experience pages, such as the pages inside a workspace.Learn more .

What an experience is

An experience is one complete app in Next Experience, with its own address, its own frame and its own set of pages. Service Operations Workspace is an experience. So is the HR Agent Workspace, and so is the main Next Experience interface itself, which you see when you log in.

Every experience is stored as a record in the UX Application table, sys_ux_page_registry. The two fields that matter most for now are:

Field What it means Example
Title The experience’s name Service Operations Workspace
Path The part of the URL that identifies the experience sow

The path is why experiences are easy to recognise. Every Next Experience address starts with /now/, and the next part is the experience path. So /now/sow/home is the home page of the experience with the path sow, and /now/nav/ui/home is the home page of the main interface, whose path is nav/ui.

What an app shell does

When you move between pages in a workspace, the header, the left sidebar and the row of open record tabs never disappear. They are not part of any page. They belong to the app shell, the frame the experience draws once and keeps on screen while the pages inside it change.

This saves an enormous amount of work. Nobody builds a header or a navigation bar for each page. The shell provides them, every page plugs into it, and the whole experience feels like one app instead of a collection of separate screens.

Different kinds of experiences use different shells:

App shell What it gives you Used by
Unified Navigation shell The main Next Experience header with All, Favorites, History and Workspaces menus The main interface you see after logging in
Workspace shell A header, a left sidebar of pages and tabs for open records Service Operations Workspace and other workspaces
Portal shell A website-style header and footer Portals built with UI Builder

When you create a new experience in UI Builder, choosing the app shell is one of the first decisions, because it shapes how the whole app looks and how users move around in it.

How a URL becomes a screen

Here is where everything connects. A Next Experience address is not just a link. It is a set of instructions that tells ServiceNow which experience to open, which shell to draw, which Page (UI Builder)One screen inside an experience, such as a home page or a record page, with its own URL.Learn more to show and which record to load.

Press Play to follow one address all the way to the screen.

InteractiveFollow one URL into an experience
  1. Step 1 of 6 · URL

    An agent opens a link

    Priya clicks a link to an incident in Service Operations Workspace. Every part of this address means something, and ServiceNow reads it from left to right.

    /now/sow/record/incident/a1b2c3d4...
    Experience
    (not found yet)
    App shell
    (not loaded yet)
    Page
    (not found yet)
    Parameters
    (none yet)
    Variant
    (not chosen yet)
  2. Step 2 of 6 · Experience

    ServiceNow finds the experience

    "/now/" says this is a Next Experience address. The next part, "sow", is the experience path. ServiceNow looks it up and finds the Service Operations Workspace experience.

    Experience
    Service Operations Workspace (path: sow)
    App shell
    (not loaded yet)
    Page
    (not found yet)
    Parameters
    (none yet)
    Variant
    (not chosen yet)
  3. Step 3 of 6 · App shell

    The app shell loads

    The experience says which app shell to use. The shell draws the frame first: the header, the left sidebar and the tab bar for open records. It stays on screen while Priya moves between pages.

    Experience
    Service Operations Workspace (path: sow)
    App shell
    Workspace shell (header, sidebar, tabs)
    Page
    (not found yet)
    Parameters
    (none yet)
    Variant
    (not chosen yet)
  4. Step 4 of 6 · Page

    The page is matched

    Next comes "record", the page path. ServiceNow finds the Record page in this experience. The rest of the address, "incident" and the sys_id, are handed to the page as parameters, so it knows which record to show.

    Experience
    Service Operations Workspace (path: sow)
    App shell
    Workspace shell (header, sidebar, tabs)
    Page
    Record (path: record)
    Parameters
    table = incident, sysId = a1b2c3d4...
    Variant
    (not chosen yet)
  5. Step 5 of 6 · Variant

    A variant is chosen

    The Record page has several variants. ServiceNow checks them in order and picks the first one whose audience and conditions match Priya and this record. She is an ITIL agent looking at an incident, so she gets the incident variant for agents.

    Experience
    Service Operations Workspace (path: sow)
    App shell
    Workspace shell (header, sidebar, tabs)
    Page
    Record (path: record)
    Parameters
    table = incident, sysId = a1b2c3d4...
    Variant
    Incident record for agents
  6. Step 6 of 6 · Screen

    The screen appears

    The chosen variant fills the space inside the shell with its components: the incident form, the activity stream and related lists. If Priya now opens a list from the sidebar, only the page changes. The shell around it stays exactly where it is.

    Experience
    Service Operations Workspace (path: sow)
    App shell
    Workspace shell (header, sidebar, tabs)
    Page
    Record (path: record)
    Parameters
    table = incident, sysId = a1b2c3d4...
    Variant
    Incident record for agents

Notice that the parts of the address map directly to the pieces you met in the previous lesson. The experience path picks the experience, the experience brings its app shell, the page path picks the page, and the rest of the address becomes parameters the page uses. Then a VariantOne version of a UI Builder page. A page can have several variants, and each user sees the one meant for them.Learn more is chosen, which is the subject of the next lesson.

See it in your instance

  1. Log in to your PDI (Personal Developer Instance)A free ServiceNow instance you get from developer.servicenow.com to practise on safely.Learn more and open /now/nav/ui/home. This is the main Next Experience interface. Notice the header with All, Favorites and History: that is the Unified Navigation app shell.
  2. Click All, find Incident > All and open it. Look at the address bar. It now looks like /now/nav/ui/classic/params/target/incident_list.do. The classic incident list is being shown inside the Next Experience shell.
  3. In the All menu filter, type sys_ux_page_registry.list and press Enter. This is the UX Application table: every experience on your instance.
  4. Look at the Path column. Find the experience with the path nav/ui, the one you just used.

Practice: app shell or page?

PracticeIs it part of the app shell or the page?

Picture Service Operations Workspace. For each part of the screen, decide whether it belongs to the app shell (the frame) or to the page inside it.

  1. The header across the top, with the logo, global search and your profile picture.

    Answer: App shell. The header is the same on every page of the experience, so it belongs to the frame, not to any one page.

  2. The incident form showing Caller, Short description and Priority.

    Answer: Page. The form only appears on the Record page and changes with the record you open, so it is page content.

  3. The icons down the left side that take you to Home, Lists and the Inbox.

    Answer: App shell. This navigation sidebar stays put while you move between pages. That is exactly what an app shell is for.

  4. The charts showing open incidents by priority on the workspace home page.

    Answer: Page. The charts are components placed on the Home page. Open a different page and they are gone.

  5. The tabs along the top that keep several open records within reach.

    Answer: App shell. The record tabs live in the workspace frame, so they stay visible whichever record or list you are looking at.

  6. The activity stream with work notes and comments next to the form.

    Answer: Page. The activity stream is a component on the Record page, tied to the record that page is showing.

  7. The notification bell that shows a count of new alerts.

    Answer: App shell. Notifications are available from anywhere in the experience, so the bell sits in the shared header of the shell.

  8. The list of incidents assigned to your team, with filters above it.

    Answer: Page. The list and its filters are the content of a List page. The shell only gives it a place to appear.

What’s next

You now know what Next Experience is, what an experience and an app shell are, and how a /now/ address leads to the page on your screen. In the next lesson, Pages, variants and audiences, you will see how one page can look completely different for different users, and how ServiceNow decides which version each person gets.

Quick check

Two pages in the same workspace both show the same header, left sidebar and record tabs. Where does that shared part come from?

Show answer

The app shell

The header, sidebar and record tabs belong to the experience’s app shell, the frame that stays on screen while the pages inside it change. Neither page builds them itself.

Was this lesson helpful?

Spotted a mistake, or a step that looks different in your instance?

Send feedback

Ideas, mistakes, anything confusing: it all comes straight to us, and we read every message.

What is it about?

The page you are on is sent with your message. Privacy