SylvainHauserN2
ServiceNow Employee

The Future of ServiceNow UI Is Here. Build Your First Lux Experience in Minutes.

 

The future of ServiceNow UI is here, and building modern, interactive experiences has never been easier!

 

With ServiceNow Lux, you can create rich user experiences using natural language and an AI coding assistant, directly from your development environment.

 

🛠️ Install. 🔗 Connect. 📁 Create. ✨ Prompt. 🚀 Deploy.

 

To illustrate what's possible, I built Campus 360, an interactive IT operations experience featuring a 2.5D floor plan, configuration items, incident reporting and visual service impact.

 

Lux Campus 360 demoLux Campus 360 demo

The initial application was generated and deployed in just 10 minutes, using a single prompt. A second prompt added richer interactions without rebuilding the original experience.


Step 1. 🛠️ Install VS Code and the Lux Lab extension

First, download and install Visual Studio Code if you don't already have it.

Then install the ServiceNow AI Experience Lab (Lux Lab) extension from the VS Code Marketplace.

VS Code install Lux.png

For detailed installation instructions, including prerequisites and environment configuration, follow the official documentation: Install ServiceNow AI Experience Lab for VS Code

You'll also need an AI coding assistant supported by your development environment. For this example, I used Claude Code.

 

Prefer a standalone application?

ServiceNow also provides a free Lux Lab desktop application for macOS and Windows, so VS Code isn't your only option: Install the standalone Lux Lab application

 

For this walkthrough, I'll focus exclusively on the VS Code extension.

 

Step 2. 🔗 Connect to your ServiceNow instance

Open the Lux Lab extension in VS Code and follow the connection workflow. 

You'll need a compatible ServiceNow development instance and an account with the required development permissions. For my example, I used an admin account: https://www.servicenow.com/docs/r/application-development/connecting-lux-lab-to-an-instance.html

Connect instanceConnect instance

Once connected, you're ready to build your first experience!

 

Step 3. 📁 Create your first Lux project

From the Lux Lab extension, create a new project.

Choose a project name and local development folder, then select:

  • Standalone application

  • Open in New Workspace (If you want a dedicated left navigation menu)

New projectNew project

Follow the setup wizard, and the extension will prepare the project structure for you.

This took approximately 2 minutes in my environment.

 

Step 4. ✨ Describe what you want to build

Now comes the fun part!

Open your AI coding assistant and describe the application you'd like to create (Claude Code for me).

You don't need to start with something complicated. A dashboard, a workspace or a simple interactive application is enough.

 

For my example, I wanted to experiment with a visual IT operations interface.

Here's a simplified version of my first prompt:

Create a ServiceNow Lux application called Campus 360.

Build a single-page, interactive 2.5D university floor plan with eight rooms: lecture theatre, two classrooms, computer lab, server room, library, IT support and reception.

Use a modern, clean ServiceNow AIUX design with a full-screen layout and no scrolling.

Add interactive IT devices across the building, including servers, switches, Wi-Fi access points, projectors and workstations.

Each device should have a coloured health indicator. Clicking a device should smoothly zoom into its room and display a floating information card.

Include KPI tiles for healthy devices, active incidents and critical incidents, plus a subtle activity feed.

Use simulated data for now. Don't create backend integrations or additional tables.

Keep the implementation lightweight, reuse components and prioritise a polished, working experience.

Build, test and deploy the application to my connected ServiceNow instance.

Then let the agent work its magic!

Depending on the complexity of your request, execution might take a few minutes or considerably longer (some of my complex prompts took 20 minutes).

One of my favourite parts is watching the agent work through its own diagnostics: opening a browser, checking the result, identifying issues and automatically applying corrections.

It genuinely feels like magic!

VS code PromptVS code Prompt

For this example, the entire build and deployment took just 9 minutes, consumed approximately US$1.10 in Claude credits, and worked on the first attempt.

 

Step 5. 🚀 Deploy and enjoy!

Once the application is built, it will deploy automatically to your ServiceNow instance using the Lux Lab deployment workflow. Open the generated AIUX experience URL.

And there you have it: your first Lux experience running on ServiceNow!

VS Code LiveVS Code Live

Of course, your first result doesn't have to be your final one.

 

I also experimented with building a complete Formula 1 Race Control Centre, featuring an interactive circuit, operational dashboards and ITSM workflows.

That one was a much more ambitious project, involving approximately 15 substantial prompts!

My approach? I used ChatGPT to help structure and refine the prompts based on my ideas, then Claude Code to implement them.

 

💡 A few tips from my experiments

  • Focus on the user experience first. Get the interface and interactions right before adding unnecessary complexity.

  • Describe interactions, not just appearance. Explain what should happen when users click, filter, zoom or submit.

  • Take advantage of ServiceNow data. Once your experience is working, connect it to real platform records, such as CMDB configuration items, incidents or approvals. Simulated data is useful for initial experimentation, but real data is where the platform becomes especially valuable.

  • Keep your first prompt focused. Add complexity in subsequent iterations.

  • Test the deployed application. A successful local build doesn't always guarantee everything will work inside the ServiceNow interface.

  • Be explicit about what you don't want. Constraints help prevent unnecessary complexity. If you're building a quick demo, say so! Otherwise, the agent might spend time and tokens implementing production-grade security, extensive error handling or features you don't need yet.

 

🎯 Want to replicate my Campus 360? Here are the prompts!

You can reproduce the experience using just two prompts.

Start with a new Lux project in VS Code, connected to your ServiceNow development instance. I used Claude Code as my AI coding assistant.

The first prompt creates the interactive visual experience. The second adds more advanced CMDB and ITSM interactions.

Both use simulated data, so you can experiment without creating ServiceNow records or configuring integrations.

Prompt 1: Build the Campus 360 experience

Copy and paste the following into your AI coding assistant:

Build a new ServiceNow Lux application called Campus 360, using the current Lux project.

Objective

Create a visually impressive, single-page IT operations experience featuring an interactive 2.5D university floor plan.

Visual design

Create a clean, professional isometric 2.5D cutaway of a single-level university building.

Include eight rooms: Lecture Theatre, Classroom A, Classroom B, Computer Lab, Server Room, Library, IT Support and Reception.

Use simple, realistic furniture, equipment and raised walls to make the rooms recognisable.

Use a fixed elevated camera angle, neutral colours, subtle shadows and modern ServiceNow AIUX styling.

The building should occupy most of the available viewport.

Use a full-screen responsive layout without vertical scrolling or a permanent right-hand sidebar.

Use lightweight SVG, CSS and standard Lux components where appropriate. Avoid external 3D engines and unnecessary dependencies.

Interactive configuration items

Add eight simulated IT configuration items distributed across the building.

Include a mixture of servers, network switches, Wi-Fi access points, projectors and workstations.

Display each CI using a small, interactive status marker.

Use green for healthy devices and amber/red for devices with reported issues.

Clicking a marker should smoothly zoom into the relevant room and open a contextual floating information card.

The card should show the CI name, type, status, location and related simulated incidents.

Support mouse-wheel zoom, drag-to-pan and a Back to Overview action.

Dashboard elements

Add three floating KPI tiles: Healthy Devices, Active Incidents and Critical Incidents.

Add a compact activity feed showing recent simulated IT events.

Include subtle status animations and connection indicators where useful.

Keep all cards and controls integrated into the map, rather than using a separate dashboard sidebar.

Data and architecture

Use a small, centralised JavaScript data store with realistic simulated CMDB and incident data.

Keep the components reusable and the architecture straightforward.

Do not create backend tables, ACLs, integrations or server-side scripts.

Do not modify other applications or shared components.

Preserve the native AIUX navigation and Help panel configuration, including helpPanel: true where supported.

Do not build a custom chatbot or modify Now Assist deployments.

Implementation

Prioritise a polished, working experience over unnecessary technical complexity.

Avoid elaborate 3D assets, external rendering engines and production-grade features that are not needed for this demonstration.

Build and test the application, including its interactive behaviour.

Deploy it to my connected ServiceNow instance using the existing Lux deployment workflow.

Provide the deployed application URL and a brief summary of the result.

Expected result: A working, interactive university floor plan with eight selectable IT assets, contextual information, smooth zoom and a compact operational dashboard.

Prompt 2: Add incident reporting and visual service impact

Once the first experience is deployed and working, use this second prompt:

Enhance the existing Campus 360 Lux application with richer CMDB inventory, simulated incident management and visual service-impact analysis.

Important: Preserve the existing floor plan, architecture, room positions, camera controls, styling and overall layout. Extend the existing application rather than rebuilding it.

1. Expand the CMDB inventory

Increase the inventory to approximately 23 interactive CIs across the eight rooms:

Lecture Theatre: AV controller, projector, audio processor, lecture capture system.

Classroom A: Wi-Fi AP, interactive display, teacher workstation.

Classroom B: Wi-Fi AP, interactive display, teacher workstation.

Computer Lab: network switch, workstation group, printer, Wi-Fi AP.

Server Room: application server, core switch, firewall.

Library: self-service kiosk, printer.

IT Support: technician workstation, management server.

Reception: printer, visitor kiosk.

Reuse the existing marker component and avoid overlapping markers.

2. Introduce CMDB dependencies

Create approximately 15 meaningful directional relationships between the CIs, inspired by ServiceNow CMDB relationships such as Depends on::Used by.

For example:

Classroom Wi-Fi access points depend on the Core Switch.

Lab workstations depend on the Lab Network Switch.

Projector and audio processor depend on the AV Controller.

Lecture Capture depends on the Application Server.

Store these relationships in a simple central configuration array.

Implement lightweight dependency traversal with cycle protection to calculate potentially impacted downstream CIs.

Do not introduce a graph library or build a full Service Mapping or CSDM engine.

3. Report an issue from any CI

Add a Report Issue action to every CI's contextual card.

Allow the user to select:

Degraded

Unavailable

Intermittent

Include an optional short description.

On submission:

Create a simulated incident with a realistic incident number.

Associate it with the selected CI.

Assign a demonstration priority using a simple documented mapping.

Update the CI status and dashboard KPIs.

Add an entry to the activity feed.

Recalculate downstream service impact.

Remove any global outage simulation button. The user should initiate issues directly from the relevant device.

4. Visualise service impact

Use the following status colours:

Red: CI with a reported complete outage.

Amber: CI with a reported degraded or intermittent issue.

Orange: CI potentially impacted by an upstream dependency.

Green: healthy CI.

A CI with its own direct issue must retain its direct-issue status rather than being overwritten by an inherited impact.

When an incident is reported:

Highlight the affected CI and its potentially impacted downstream CIs.

Display subtle animated dependency lines between relevant devices.

Dim unrelated dependency connections.

Show a compact floating Service Impact card identifying the source CI and number of potentially impacted devices.

Allow users to focus on the upstream source when selecting an impacted CI.

Keep the impact card integrated into the floor plan, not in a permanent sidebar.

5. Resolve incidents

Add a Resolve Incident action.

When an incident is resolved:

Update its simulated state.

Recalculate impact based on all remaining active incidents.

Restore healthy indicators only where no other active issue or dependency impact remains.

Update KPI tiles, activity feed and dependency animations.

Support multiple simultaneous incidents without one resolution incorrectly clearing another incident's impact.

6. Add inventory filters

Add four compact filters:

All CIs

Infrastructure

Endpoints

Impacted

Filtering should change marker visibility only, without modifying incident or dependency data.

7. Keep the implementation lightweight

Reuse the existing components and central data store.

Use simple JavaScript, SVG and CSS.

Keep all data simulated.

No new backend records, integrations, tables, roles or ACLs.

No external graph or 3D libraries.

No Change Management, Problem Management or approval workflows.

Do not modify the native AIUX shell, Help panel, Otto configuration or unrelated applications.

Keep the application within the available viewport without scrolling.

8. Test and deploy

Verify that all 23 CIs can be selected, incidents can be reported and resolved, service impact is calculated correctly, filters work, and the existing zoom/pan behaviour remains functional.

Test multiple simultaneous incidents and their resolution.

Build and deploy the enhanced application to the same ServiceNow instance.

Report what was implemented, tested and deployed, along with any remaining limitations.

Prioritise a working demonstration over unnecessary implementation complexity. Do not redesign the existing experience.

Expected result: A visual IT operations experience where you can select any CI, report an incident, immediately see its potential impact on dependent devices, and resolve the incident to restore the campus to a healthy state.

 

 

That's it!

Two prompts. One interactive ServiceNow experience.

 

And that's just the beginning. Campus 360 uses simulated data to keep things simple, but the same approach can be extended with real ServiceNow records, workflows and integrations.

 

The hardest part might actually be deciding what to build first!

 

Give it a try, experiment, and share your results in the comments. I'd love to see what you create.

 

Version history
Last update:
2 hours ago
Updated by:
Contributors