Brad Tilton

5 minute read

As we learned last week, the first thing you’ll do when working with experiences in UI Builder is create or open an experience and create a new page. When you create a new page you’ll be able to add containers, components, data resources, and more to the page.

This week, we’ll look at pages a little more closely and explore pages and their settings, parameters, templates, and variants.

Page Templates

When you create a new page in UI Builder, you’ll have the option to create a blank page or a page from a template. A blank page gives you a page with nothing on it where you can add whatever containers and components you’d like in whatever structure you’d like. Alternatively, if you create a page from a template you can choose from a number of different options that can jumpstart your page creation process. This is really helpful if you’re creating a standard page type like a list or form view of a table. You end up with a page that has containers, components, data resources, client state parameters, and/or client scripts already configured for that page.

When you are creating a page from a template it will ask you How would you like to add content to this page? and you’ll have two options:

  1. Reference the page template and its data: This creates a read-only version of this page that references the page template. When you upgrade your instance release version the page will automatically be upgraded if there are changes in that release. This helpful because you’re basically letting ServiceNow manage this page for you. The downside is that you cannot customize this page as it is read-only.

  2. Only copy the contents of the template: This creates a copy of the template page that you will then be able to customize. The benefit is that you can customize this page so that you can optimize it for your information, but the downside is that it won’t receive updates at upgrade time if the template happens to change.

Neither of these options is necessarily better or worse than the other in a vacuum, you’ll just want to make sure that you assess the level of risk with this decision the same you would any other architectural decision on the platform. Here’s a quick video running through creating a page from a template.

Before creating any pages from scratch in UI Builder you should familiarize yourself with the templates already provided. You may not find one that fits your use case, but you could save time if you do.

Page Parameters

Page parameters let you pass data through the URL to the page itself, and they can be either required or optional.

  • A required parameter is a piece of data that your page requires, such as a sys_id, table, or query. Required parameters are useful for components because they can bind to the value of the required parameter.

  • Unlike required parameters, optional parameters are always name and value pairs that work no matter what order that they are provided in.

You can reference the page parameters in your components as shown in the video below.

Page parameters are useful for passing data to your page through the url, and being able to access that data from a component or page client script.

Page Variants

Page variants are an exciting feature for those who need different versions of pages for different audiences. A variant is basically a different version of a page that you can display to a different type of user or in different circumstances. Each variant of a page would share the same URL, but the layout, contents, and behavior of the page could be slightly to very different. In the Service Portal you would have to do something like this either on a per widget basis or within a widget itself. When you create a page it automatically creates a default page variant, and you can add additional variants from there.

To control when a specific variant is shown for your page’s route (URL) you can configure:

  • Audiences - Show the page to a specific group, role, etc.

  • Conditions - Use an encoded query and an order field to show the page based on the data being passed in the page route (URL).

This means that you can show different versions of a page to someone based on who they are AND based on what is being passed to the page through the URL. Here’s a quick example of how that works.

Page variants allow you to easily show what content is shown on the page based on both the audience and page data.

What’s Next?

We’ve explored how you can create a page from a template and speed up your page development, add required and optional url parameters to your page in order to make your page more dynamic, and use different variants to show different versions of your page to different audiences or based on the page data.

Stay tuned as we’ll have new UI Builder related content every week here on the developer blog. We’ll get into data resources, client state variables, client scripting, headers, modals, and more!