| < Previous Article | | Next Article > |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Link to previous article | | Link to next article |

---

Overview

This guide is written by the ServiceNow Technical Support Performance team (All Articles). We are a global group of experts that help our customers with performance issues. If you have questions about the content of this article we will try to answer them here. However, if you have urgent questions or specific issues, please see the list of resources on our profile page: ServiceNowPerformanceGTS

This article is written to discuss common best practices that can be used to avoid performance issues with ServiceNow's Next Experience products. These products include Configurable Workspace, UI Builder, Unified Navigation, Portal Experiences and more.

You can find out lots of great information about Next Experience at the Community Product Hub here: Community Product Hub for Next Experience [Official ServiceNow Community site]

To understand about some of the tools available to troubleshoot performance issues in Next Experience see the page How to troubleshoot Failing Transactions in Next Experience Workspace or Portal Experiences - KB1640661 [Public facing SN authored KB article on Now Support portal]

Table of Contents

1. Don't pass null/undefined variables to Look Up Record
2. More to come...

Don't pass null/undefined variables to Lookup Data Resources

[Video to come]

The "Look up a single record" or "Look up multiple records" Data Resources (sys_ux_data_broker table ) allow users to search and retrieve specific information from ServiceNow's database based on the provided search criterion. They can be added through UI Builder. Behind the scenes, these Data Resources use GlideRecord. So, all of the performance implications of a GlideRecord operation also apply to a Lookup. If you've read our other blog post Performance Best Practices for Server-side Coding in ServiceNow [Community blog by SN] perhaps you recall that the number one cause of performance issues we see in ServiceNow is undefined or null variables being passed to GlideRecord. Well, since Lookups calls GlideRecord in the background, this same principle exists in Lookups as well.

See All About Data Resources in UI Builder, by Brad Tilton (ServiceNow developer advocate)

How to validate your bind variables

Select the Data Resource you want to add. Click "Add". After that, one of the first choices you will need to make is when to evaluate the data resource. You can choose to have the data resource evaluated immediately on page load (eager) or whenever one of the bind variables is updated (explicit). If you are using variables (i.e., binding data) to define the filter of your Data Resource, you should choose "explicit". Then you need to define an event handler that will trigger the Data Resource execution by updating your bind variable. One way would be to define a Client Script that handles the "body" component's "Page ready" event. In the script you would validate that the data you want is available and only update your bind variable if all the data is present. See Creating An Event Mapping [Official ServiceNow Dev].

The "Only when invoked" option is a little confusing as it will fire whenever the bind variables are updated, so this might not be the behavior you want. See the following community question discusses this dilemma:

https://www.servicenow.com/community/next-experience-forum/can-i-disable-a-data-resource-until-all-of-the-required-inputs/td-p/3243381

If you do not use the explicit option, then there will be no time for you to verify your bind data before the Data Resource executes. If the bind data is not available at the time of execution of the Data Resource then the condition will be evaluated as if a null value has been passed into the filter condition.

So instead of fieldName= the query will execute with the condition fieldName=null. If there are 10 million records with fieldName=null, then this could cause a really slow query and annoy your users.

---

| < Previous Article | | Next Article > |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Link to a previous article | | Link to the next article |