CodeVerse Creatives
Esc
ServiceNow Syllabus / Module 22 of 25 / Week 22

Week 22: UI Builder & the Shift Beyond AngularJS

Every widget you've built since Week 10 runs on AngularJS 1.5. UI Builder is ServiceNow's newer, component-based answer to "what comes after" — and this week is about understanding it well enough to make a real choice, not just knowing it exists.

Module 22 of 25 Week 22 of 26 ~3–4 Hours Hands-on Exercise Included

By the end of this week, you'll be able to

  • Describe UI Builder's page/component/data-resource model
  • Explain how client state and events work in a UI Builder component, at a conceptual level
  • Make an informed choice between UI Builder and Service Portal for a new project
1 Pages, Components, Data Resources 2 Client State & Events 3 UI Builder vs. Service Portal 4 Exercise 5 Knowledge Check

1. Pages, Components & Data Resources

UI Builder builds pages out of pre-built and custom components — self-contained UI pieces with their own configurable properties, dropped onto a page and wired to data sources called Data Resources (a GlideRecord-backed data source, a Scripted REST API call, a server script — conceptually similar to what a widget's server script provided, but configured declaratively per-component rather than written as one server script per widget).

Why this exists alongside Service Portal, not instead of it

UI Builder is the platform's forward-looking, actively developed direction for building custom UI — but Service Portal remains fully supported and is still what the vast majority of existing customer portals run on. Neither has fully replaced the other yet, which is exactly why both are worth understanding.

2. Client State & Events (Conceptually)

Where a widget's client controller holds all its own state on c and relies on AngularJS's digest cycle to re-render (Week 11), UI Builder components communicate through a more structured, declarative events and client state model — a component can expose events other components or the page can react to, and read/write named pieces of page-level client state, configured through UI Builder's interface rather than hand-written $rootScope.$broadcast calls (Week 14).

The underlying goal is the same problem Week 14 solved by hand — components on a page reacting to each other's changes — just with more of the wiring handled declaratively by the framework instead of written as controller code.

3. Choosing UI Builder vs. Service Portal

For new work today, a reasonable default: reach for UI Builder when starting something genuinely new with no existing investment either way, since it's the platform's actively evolving direction and increasingly the default recommendation for new experiences. Stay in Service Portal when extending an existing portal with years of custom widgets already built — rewriting a mature portal wholesale is rarely worth it just to be on the newer framework, and your AngularJS widget skills from Weeks 9–15 remain directly relevant maintenance work for a very long time to come.

4. Hands-on Exercise

Hands-on

Build a simple UI Builder page and compare it to your widget

Requirements:

  1. Open UI Builder (System Applications > UI Builder, or the equivalent on your instance's release) and create a new experience/page.
  2. Add a Data Resource backed by the incident table, filtered to a small set of records.
  3. Drop a List or Table component onto the page and bind it to that data resource, displaying number and short_description.
  4. Write a short comparison (a few sentences) of what steps this took versus building the equivalent my-open-incidents widget back in Week 10 — what got easier, what got less flexible.

5. Knowledge Check

Four quick questions. Expand each to check your answer.

Q1

What plays the role in UI Builder that a widget's server script plays in Service Portal?

A Data Resource — a configured, declarative data source (GlideRecord-backed, a Scripted REST API call, or similar) that a component binds to, providing data to the page conceptually similarly to how a widget's server script populates the data object, but configured per-component rather than written as one custom script.

Q2

How does component communication in UI Builder relate to the $broadcast/$emit pattern from Week 14?

It solves the same underlying problem — components on a page reacting to each other's changes — but through a more structured, declarative events-and-client-state model configured through UI Builder's interface, rather than hand-written $rootScope.$broadcast/$emit/$on calls in controller code.

Q3

Why hasn't UI Builder simply replaced Service Portal across the platform?

Service Portal remains fully supported and is still what the vast majority of existing customer portals run on — rewriting a mature portal with years of custom widgets already built is rarely worth doing just to move to the newer framework, so both continue to exist and be maintained.

Q4

What's a reasonable rule of thumb for choosing between the two for a given project?

Default to UI Builder for something genuinely new with no existing investment either way, since it's the platform's actively evolving direction. Stay in Service Portal when extending an existing, already-built-out portal, where the AngularJS widget skills and existing widget library remain directly relevant and a full rewrite isn't justified.

← Back to Week 21 Up next Week 23 →