How to troubleshoot Slow Transactions or Page Load Issues in Next Experience Workspace and Portal Experiences<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } Overview This article is aimed at ServiceNow customers and partners who are trying to solve performance issues (e.g., slow response times or page load failures) in Workspace Experiences. Before bringing your issue to ServiceNow support, it can be very helpful to see if you can troubleshoot it yourself. This has two benefits. First, you might solve the issue yourself, saving time and making you look like a hero (time for a pay raise!). Secondly, if you aren't able to completely solve the issue, you will have solid information that you can provide to ServiceNow support when you open your case. Table of Contents OverviewServiceNow Performance Metrics: Client Interactions and Transaction LogsA Good Problem Statement Template for End Users to Help Collect Data Common Types of Failing TransactionsClient Interactions How "Total UI Time" WorksSeeing Client Interactions per "Application"Understanding "Screen Routes", "Screen Fields" and "Screen Params" Transaction LogsNED Tools (Next Experience Developer Tools) ServiceNow Performance Metrics: Client Interactions and Transaction Logs A Good Problem Statement The most helpful thing that you can do when troubleshooting an issue is to develop a clear problem statement. This will be helpful when handing the issue to ServiceNow, but it will be just as helpful to everyone involved because it will help direct and focus troubleshooting efforts. If you aren't sure what the problem is, you and your team may waste precious time looking at irrelevant details. Always ask yourself, what details would someone else need to immediately start investigating this issue? Those are the details you need to provide in your problem description. A good problem statement may include some or all of the following items: Detailed historical examples of the issues, so you can find the relevant logs 👈 THIS IS THE MOST HELPFUL THING! Ideally, the best way to document an historical example is by keeping a link to the relevant Transaction (syslog_transaction) or Interaction (sys_client_interaction) record in your ServiceNow instance. Keep in mind that Transactions and Interactions do not last forever, they are rotated every 7 days. It is best to export or copy the important details of any historical examples for future reference.If you don't have a link to the relevant transactions/interactions, then the important details to record include the following: Exact times to the second, if possible (please, please, please include the timezone 😬 - a great tool for Timezone conversions and documentation is https://www.timeanddate.com/worldclock/converter.html)User namesActions they were takingURLsScreenshotstransaction numberInteraction ID A clear description of the overall issue. What is the problem? Include expected vs. unexpected behavior. How slow is slow, 3 seconds or 3 minutes?Where is this observed? Environments, versions, workspaces, applications, mobile, desktop, virtual machines, regionsWho is impacted? Is it a certain group of users? Please provide exact user names of users who have complained so ServiceNow can look at their logs.When does it happen? All day or just certain times? When did it seem to start? Has it been getting worse? A clear description of what is NOT the issue What is NOT the problem?Where is this NOT observed?Who is NOT impacted?When does it NOT happen? Distinctions between different flavors of the issue. You might actually have multiple issues, so being clear about the different symptoms will help clarify the investigation.Steps to reproduce the issue Complete: Include all steps from the time of login, don't assume someone will know that you've skipped a stepDiscrete: Include only one sequential step at a time.Concrete: Use language that describes real actions (e.g., "Click the Submit button in the header of the Case form" rather than "Submit a new Case"))Also include pre-requisites (e.g., turning on a plugin, what environment, what user to impersonate etc.) Good ExampleLess Good (AKA Bad) Example We have been seeing periodic slow page loads (many over 20 seconds) in the Software Asset Workspace (go to https://acme.service-now.com/now/softwareasset/home) since around mid January. There are many examples of this issue - maybe, 3 or 4 per day. We can't look into all of them, but one example we looked at was user Abel Tutor (abel.tutor) who waited over 30 seconds while trying to view unassigned Assets on Feb 2, 2024 at around 11:00 US Central (UTC -6). We followed the steps to find the related Transaction logs, but no transactions with response_time over a couple seconds were found. Steps to reproduce Impersonate abel.tutorOpen Software Asset WorkspaceClick the lists icon from the left navClick the "Unassigned Assets" listThe list of records should come up in 3 to 4 seconds but when the issue happens, users see the top of the list start to render then a spinning wheel for up to 20 seconds before the list of records comes up. Query we used to find example transactions: https://acme.service-now.com/syslog_transaction_list.do?sysparm_query=sys_created_onBETWEENjavascript:gs.dateGenerate('2024-02-02','10:50:00')@javascript:gs.dateGenerate('2024-02-02','11:20:00')^sys_created_by=abel_tutor The users are raising ongoing performance issues on workspaces in AM area. Notice what this example does well. It quantifies all the details as accurately as possible. The steps to reproduce don't just say "doesn't load" or "loads slow", those are relative and ambiguous terms. Even though the exact transaction records weren't able to be found, they have explained that issue often takes more than "20 seconds" - a very helpful detail. In addition, this example gives some important concrete details about what the users see - for example, it states they will see "the top of the list start to render then a spinning wheel". Also while this example isn't able to give the exact time the user hit the issue, it does provide a very close approximation both with the link to the transaction table and the verbal explanation that it occurred at around 11:00 US Central (UTC -6). This is enough information for someone else to find the logs relevant to the example transaction or to reproduce the issue themselves. Armed with this problem description, someone could immediately start troubleshooting. Template for End Users to Help Collect Data In some cases you may have intermittent issues that cannot be reproduced on-demand. In this case, it may be helpful to solicit help from the end users who are reporting the issues. Below is a VERY comprehensive list of instructions you might choose to provide your end users to aid them in collecting observational data when the issues occur. You may copy and paste some or all of the following instructions to your end users. We recommend only giving the minimal necessary instructions so as not to overwhelm them: ----- Begin Instructions to Assist Collecting Evidence ----- To help us assist you with your issue, please collect the following whenever you experience the issue(s). (Most important) Collect Historical Examples Include all of the following: User nameActions that were takenExact times (please include the timezone - a great tool for Timezone conversions and documentation is https://www.timeanddate.com/worldclock/converter.html)Expected vs. Unexpected behavior (e.g. form took 30 seconds to load when normally it takes 3 seconds) Optionally, include the following: URLsScreenshots ----- Additional detailed diagnostics if needed ----- If browser seems to slow to a crawl: Open the Task Manager and take a screenshot Right+click the right most area of your browser header (past the tabs)Click “Task Manager” in Chrome, “Browser task manager” in EdgeTake a screenshot and be sure to get Memory usage, CPU and Javascript memory If all above has not helped: Collect a HAR file Detailed instructions can be found at the following article for how to do this in multiple browser types: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0994933 If all above has not helped: Collect a Performance Trace Detailed instructions for collecting a Performance Trace in Chrome browser can be found at the following: Performance features reference [Google official doc] If all above has still not helped or if network requests seem to hang but no high server processing is observed: Take Pings and Traceroutes to check for network issues Pings: To use ping, open a terminal window, type ping followed by the instance name (for example, instance.service-now.com), and capture the output. This works on Mac, Windows, or Linux/UNIX. Traceroutes: To use traceroute:Windows: tracert <instance>.service-now.comMac/Linux: traceroute –I <instance>.service-now.com Thank you! ----- End Instructions to Assist Collecting Evidence ----- Common Types of Failing Transactions There are a two basic types of failing transactions: transactions that break and transactions that load slowly. While these issues look similar, they have very different causes. For example, suppose your symptom is a blank white screen after you click a button. This could be caused by a page that is breaking (some logic is failing and thus not loading as expected) or a page that is running slowly (the page is loading, but it just takes a long time, maybe even so long that it never loads or times out). It is important to understand which type of issue you are dealing with because they require very different skillsets to diagnose and remediate. Figuring out what type of issue you are dealing with will help ensure that the right resources with the appropriate skillsets are engaged to solve the issue. Pages that break - i.e., a type of functional issue, often perceived as slowness, where pages don't load at all or they render incorrectly Causes and troubleshooting steps include the following: A business logic failure on the server that resulted in a failed transaction Symptoms These usually shows up as a "Internal Server Error 500..."Page never rendersLack of slow transactions or interactions in the ServiceNow logs. Diagnostic Steps See UI Builder shows Internal Service Error (500) - KB1702222 A transaction that gets cancelled due to another transaction from the same user Symptoms "Internal Server Error 500"Page never rendersSometimes these cancellations are due to hitting the timeout limit. In this case you may see a slow transaction or interaction in the logs from the impacted user, but it might be a different one than the one that was cancelled. Diagnostic Steps Cancelled transactions are often impacted/caused by a key feature of ServiceNow called session synch - see KB0755706 - What is Session wait / Session Synchronization?You need to identify the transaction that caused the other transaction to fail. This can often be done by looking at the transaction that occurred directly after the transaction that failed. To see a list of cancelled transactions use the Cancelled Transactions Table - see https://www.servicenow.com/docs/csh?topicname=c_CanTranLogTbl.html&version=latestTransactions can also get cancelled due to the Quota Manager. See https://www.servicenow.com/docs/csh?topicname=t_ViewACancelledTransaction.html&version=latest Rendering errors Symptoms When there is a rendering error, the UI may appear frozen or partially rendered.You may see the spinning "Loading..." wheel that never stops, but other parts of the UI are still responsive. For example, you can still easily navigate away by clicking other sections of the UI in the same page.One good clue that you might have a rendering error is if everything looks frozen, but when you resize your browser - by grabbing a corner of the window and dragging it, for example - suddenly the sections of the screen that were frozen render successfully.Lack of slow transactions or interactions in the ServiceNow logs. Diagnostic Steps One cause of rendering errors can be conflicting or broken Themes. Try setting the Next Experience Theme back to the out-of-box theme. Update the property "glide.ui.polaris.theme.custom" to "a309795273230010fd843c78caf6a724" which is the sys_id of the default theme. Conflicts with an extension or plugin for the browser Symptoms Various symptoms like pages never loading, never finishing loading, freezing.Conflicts with browser extensions usually result in broken pages, but they can also cause the page to load slowly.Lack of slow transactions or interactions in the ServiceNow logs. Diagnostic Steps Disable all extensions.Confirm the issue has gone.Turn them back on, one-by-one until the issue returns.The last extension that you enabled before the issue returned is causing the issue. Race conditions during client-side component loading. One case this can happen is when a custom page has been built using UI Builder. The cause is that Component Events in Next Experience are inherently non-deterministic/asynchronous. Symptoms Might be intermittent. The page renders fine one time and fails the next time, or under slightly different circumstances.Expected server calls do not always execute, so this can result in lack of slow transactions or interactions in the ServiceNow logs.Rendering fails half way through, leaving a half built page. Diagnostic Steps See https://developer.servicenow.com/dev.do#!/reference/next-experience/latest/ui-framework/main-concepts/code-execution for an explanation and recommendations.Check in UI Builder to see if there are any components or processes that have dependencies on each other, that are assumed to complete in a deterministic order.Check if multiple Data Resources or Components on the Screen are loading their data "eagerly", meaning that they are loading immediately on page load. Review the article: https://www.servicenow.com/community/developer-articles/performance-best-practice-for-next-experience/ta-p/3350236 that discusses "eager" vs. "explicit" Data Resources. Pages that load slowly Causes include the following: Excessive client-side processing. Symptoms In Chrome you may see "A page is loading slowly, what do you want to do? Wait for it?". Diagnostic Steps Review Client Interactions and Transactions and notice that there suspiciously no long running transactions - more suspiciously, there may be no transactions at all during the exact time that the issue is reported.Use the Next Experience Developer Tool See Troubleshooting Scenarios with NED Tools - KB1543474 Use a HAR file to capture network traffic from your browser See How to capture browser trace and generate a HAR file for troubleshooting) Use the Performance tools in Browser Developer Tools in Chrome or equivalent tool See Performance features reference [Google official doc] Example Repeater component with 1,000 results See Performance Hacks: Next Experience "Repeater" and "Pagination control" Components) Inefficient database queries Symptoms Action taken in UI, but no rendering beginsAction taken in the UI and rendering begins, but there is a long transaction on the serverSlow Transaction logs with high "SQL Time" metric Diagnostic Steps KB0692720 - How to debug SQL for a transaction to find the code which is triggering it Check if there are slow queries from Data Resources. These might be due to invalid data binding variables. See the Community blog post: Consider Validating Data Binding Conditions for Data Resources Solutions Best Practice for Building Efficient Queries Excessive server-side processing Symptoms Action taken in UI but no rendering beginsAction taken in the UI and rendering begins but there is a long transaction on the serverSlow Transaction logs with high "Transaction Processing Time" metricMany smaller Transactions connected to a Client Interaction with high "Total UI Time" or high "First Component Interactable time" Diagnostic Steps Check Client Interaction and Transaction Log for high "Transaction Processing Time" or an unusually high volume of transactionsThere are many steps covered in the following excellent article: KB0997495 - How to troubleshoot a slow transaction Solutions Performance Best Practices for Server-side Coding in ServiceNow Large pages/resources getting downloaded Diagnostic steps Check in Browser Developer tools Network tab See if the sizes of any resources are unexpectedly largeSee if the "Content Download" portion of the "Timing" information is taking a long time. Check Client Interaction "Content Download Time" Memory shortage on the browser. Symptoms The ServiceNow may seem to suddenly freeze or it may slow to a crawl.In Chrome, you may see the message "Aw, Snap! Something went wrong while displaying this webpage. Error code: Out of Memory".Other tabs in the same browser may still work fine - even tabs that are also running ServiceNowYou might see a suspicious lack of slow Transaction Logs and Client Interactions logs, or lack of any logs for the user at time of impact Diagnostic Steps Check Task Manager: Open the Chrome Task Manager (Chrome menu > More Tools > Task Manager) to identify which processes are consuming the most memory.2. Enable JavaScript memory in Task Manager: You can enable a JavaScript memory view in the Task Manager to get a more detailed view of memory usage.3. Use Chrome's Memory Profiler: Chrome DevTools includes a memory profiler that can help you identify memory leaks. Memory or processing bottlenecks on the Operating System Symptoms All websites are slow, not just ServiceNowServiceNow transaction logs show the transactions ran quickly on our serversServiceNow transaction logs show gaps in receiving transactions exactly when the issues are reported Diagnostic Steps In Mac. Use Activity Monitor.app. Open it by going to Applications > Utilities > Activity Monitor.The Memory tab within Activity Monitor will show you how much memory each process, including apps and system processes, is using. In PC, use open Task Manager (Ctrl+Shift+Esc) Navigate to the Performance tabClick on Memory to see total RAM and current usage.You can also open Resource Monitor for more detailed information Network lag/failures Symptoms User Interacts with the UI but nothing seems to happenUser Interacts with the UI and sections start rendering but then freeze for a whileMany different types of operations respond more slowly than normalConsole log shows HTTP 500, server unavailable or failure to connect messagesServiceNow transaction logs show the transactions ran within normal ranges on our serversServiceNow transaction logs show the transactions starting later than when the User interacted with the UIServiceNow transaction logs show gaps in receiving transactions exactly when the issues are reportedServiceNow Transaction logs show high "Client Network Time" metricClient Interaction shows high "Network Latency" for the impacted region (note this is a ping time, not transaction time) Diagnostic Steps See Troubleshooting Network PerformanceSee How to check GraphQL network calls in Agent WorkspaceSee ServiceNow Next Experience UI Performance Zurich Network Timing [Video] A transaction that gets cancelled because it ran longer than a quota Symptoms The Quota Manager logs each canceled transaction as a warning message in the system log.UI may display "Internal Server Error 500" Diagnostic Steps See https://www.servicenow.com/docs/csh?topicname=t_ViewACancelledTransaction.html&version=latest NOTE: A really slow transaction that times out and/or gets cancelled can look similar to a page that breaks, but the causes will be similar to other slow loading pages, rather than other pages that break. Many times, the causes of Next Experience failures are the same as ServiceNow's Core UI (also sometimes called UI16). You should familiarize yourself with the following article which includes a video tutorial KB0997495 - How to troubleshoot a slow transaction. Client Interactions The Client Interactions table (sys_client_interaction) stores information about, well... interactions. Interactions track how a user navigates within a ServiceNow website. In modern web development, when you click a button there may be hundreds of individual, overlapping transactions. So how do you measure how long it took for the page to load after you clicked a button? How do you know which transactions were related to your button push and which were not? An Interaction aggregates all those transactions into one place. But it does more than that. It also keeps track of the total time it takes from start to finish. This is ServiceNow's version of what the industry calls Real User Monitoring (RUM). As of the Washington DC release, Client Interactions were still a work in progress, but they have become increasingly robust and accurate since the Tokyo release. By Xanadu release, many important defects and enhancements were completed, with more planned over the next two releases. Zurich introduced a huge number of bug fixes and features including the Total UI time metric more reliable, making sure all transactions were connected with the correct interaction, and adding accurate network timings in the form of the Interaction Network Latency (a ping time) and Transaction Client Network Time (effectively the time for a single HTTP request/response to traverse the internet). There are many useful fields in the Client Interactions table, but the most important is probably the total_ui_time field. Total_ui_time tracks all the time between a page being requested and that page being considered "idle" (see detailed description of what idle means in the section below). It gives you a picture of what a user is really experiencing. Two other useful fields, related to total_ui_time, are ui_time_before_load and ui_time_after_load. The "load" event is essentially when the Application Shell, or app shell, has finished loading. All the time between the start of an interaction and "load" is ui_time_before_load. All the time between "load" and "idle", is ui_time_after_load. The app shell is the header banner and context menus. The app shell is not re-rendered for every Interaction, so ui_time_before_load and ui_time_after_load are not always populated. Another very useful timing field to understand real user experience is the fci_time field, or First Component Interactable Time. This gives an idea of when the user is first able to interact with a screen that is loading. In other words, it is when they are first able scroll, click, or type with a part of the UI that is loading. The following fields might be useful to add to your Client Interaction ID list layout. (The above diagram shows the relationship between Transactions and Interactions and explains some of the key performance metrics.) Fields on the Client Interaction table (sys_client_interaction) FieldDescriptiontotal_ui_timeThe duration starting when the user interacted with the UI until the UI became idletypeThe interaction type (ex: PAGE_LOAD, NAVIGATION, etc). Direct page load is when you hit the URL directly (while logged in) or visit a page on the browser post-login. Navigation is measured when the user navigates to a different screen (e.g. clicking on a list to open a record, or clicking on a toolbar icon to navigate to a different route.). IN_PAGE_INTERACTION are for interactions within a screen, like clicking a button.interruptionDefault is "none". Otherwise it indicates the type of operation that interrupted the recording of UI Time while the page was being load. For example, if there is any keydown, mousedown, browser tab switch or there are multiple navigations happening at same time (e.g. Opening multiple record page from list), these can result in an interruption. Interruptions might skew the TotalUITime because of various factors, so if you see that there was an interruption, take the timing with a grain of salt. Here are some common interruption types: PAGE_VISIBILITY_CHANGED: When your focus gets shifted away from the current page BROWSER_NAVIGATION: When user clicks the browser back and forward buttons MOUSEDOWN: When user clicks while the page loads KEYDOWN: When user uses keyboard while the page loads TIMEOUT: When any one of the page load checks time out NONE: No interruption fci_timeFirst Component Interactable time is when the user is first able to interact with a screen that is loading. In other words, it is when they are first able to scroll, click, or type with a part of the UI that is loading.network_latencyA "ping" based network timing - i.e., generic ping time from the network from which the Interaction originated at some point in time. Network latency value is not connected to the any of the transactions for the interactions themselves, it is the round trip time to fetch a separate minimal static resource. The same static resource is fetched each time and the value is cached across multiple Client Interactions. It is refreshed every 5 minutes. By looking at trends of network latency across regions you can get an idea of how users in different regions are being impacted by network performance, apart from ServiceNow application performance.total_sql_timeSum of syslog_transaction.sql_time for all transactions with a matching interaction_idtotal_sql_countSum of syslog_transaction.sql_count for all transactions with a matching interaction_idtotal_response_timeSum of syslog_transaction.response_time for all transactions with a matching interaction_idtotal_business_rule_timeSum of syslog_transaction.business_rule_time for all transactions with a matching interaction_idtotal_business_rule_countSum of syslog_transaction.business_rule_count for all transactions with a matching interaction_idtotal_network_timeAggregate from syslog_transaction.network_time via matching interaction_id (not client_network_time!) This metric is unreliable and deprecated. Do not use. To understand network time per transaction it is better to use the syslog_transaction.client_network_time metric from the related list of Transactions at the bottom of the Interaction form.total_txp_timeTotal transaction processing time refers to the sum of transaction processing times, in milliseconds, for all transactions (syslog_transaction) associated with a particular interaction. Transaction processing time measures only the time that a transaction was running on a Semaphore thread, excluding any wait times. Note that certain transactions are allowed to process in parallel.ux_screen_routeThe name of the sys_ux_app_route screen that was being loaded. A Screen is somewhat analogous to a page. Perhaps a "content pane" is a better way to describe it. A Route is a way of getting to a screen. You can have a Screen load as a modal or you can have it load as a sub-page or you can load it in a totally new browser tab. Each of these ways of accessing a Screen can be a different Route.ux_screen_fieldsThe key value pairs of mandatory "fields" from sys_ux_app_route. For example, these frequently include a sys_id and a table name to identify a record that will be displayed in the screen.ux_screen_paramsThe key value pairs of "optional_parameters" from sys_ux_app_route table.ui_time_before_loadThe "load" event is essentially when the Application Shell, or app shell, has finished loading. All the time between the start of an interaction and "load" is ui_time_before_load. The app shell is the header banner and context menus. The app shell is not re-rendered for every Interaction, so ui_time_before_load and ui_time_after_load are not always populated.ui_time_after_loadAll the time between "load" and "idle", is ui_time_after_load.linked_txc_metricsJson payload of client metrics for the transactions related to the given interaction. {sys_id:{startTime:integer(epoch),duration:integer(ms)}"duration" is the difference between startTime (value of the first recorded timestamp of a performance metric) and responseEnd(timestamp immediately after the browser receives the last byte of the resource or immediately before the transport connection is closed, whichever comes first.). See https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming for a diagram.client_cache_hit_rate Number of requests served by client network request cache / Total number of requests sent for that interaction.content_download_timeContent download time sums of duration, in milliseconds, for all network requests during the interaction window.content_download_sizeSumming the transfer sizes of all network requests during the interaction windowpage_variant_sys_idCaptures the Variant Sys Id of the screen rendered and visible to the user for which the interaction is being tracked. How "Total UI Time" Works (Beware: technical mumbo jumbo!) Seismic is the component framework in Next Experience. Seismic has a scheduler for events; e.g., renders, effects/actions, dispatches, state changes, property changes. Seismic also has a network queue for HTTP requests to be sent up to ServiceNow. In order to determine when an Interaction is complete, we pay attention to the scheduled events and outbound network requests. If we see that both are idle, then Seismic sends out a promise that says Seismic is idle. UXF is the framework that enables the declarative metadata and runtime of Next Experience. It is how Components, Screens, Routes, and Applications all get wired together to make a ServiceNow Experience, like a Workspace. UXF understands composition of the page and waits to hear that Seismic is idle. Once it does, it verifies that the page level Macroponent is actually settled. As soon as both UXF and Seismic agree that nothing else is going on, we trigger a promise that captures the current timestamp and this is how we determine the end of Total UI Time (sys_client_interaction.total_ui_time). One thing to note is that, as of Zurich, Client Interaction does not work on every little click. For example, it does not capture navigations within a single tab, like clicking the magnifying glass icon to search for records for a reference field. It only works on hard refreshes of the browser (“page” load), any time you directly type a URL into the browser to navigate, or if there is a "NAVIGATION" event - which includes things like loading a list, or loading or submitting a record, or page. There are some individual component/button push interactions that can trigger an interaction, but not all do. Seeing Client Interactions per "Application" Another useful field in Client Interactions is the "Application" field. The "Application" field can be used to see, for example, only those Interactions from the "HR Agent Workspace". You may need to personalize your list layout using the List Mechanic (cog wheel icon) to show the Application field on the list. If you have multiple reports of issues with a certain Workspace or you just want to find out the health of one of your Workspaces, you can use the Client Interaction table to investigate. You could do something very simple, like just look directly at a list of Client Interaction records, or you might want to schedule fancy weekly reports that show aggregate load times to keep you informed. Understanding "Screen Routes", "Screen Fields" and "Screen Params" In Next Experience, a Screen is somewhat analogous to a page. Perhaps a "content pane" is a better way to describe it. A Route is a way of getting to a screen. You can have a Screen load as a modal or you can have it load as a sub-page or you can load it in a totally new browser tab. Each of these ways of accessing a Screen can be a different Route. The Route is the argument immediately following the Workflow path. To pass arguments to a Screen, some details can be included in the URL. Arguments are defined in the Fields field and the Params field. Fields are required arguments and Params are optional arguments. Transaction Logs Transactions Logs have been a staple diagnostic tool in ServiceNow for many years. Transactions Logs are still relevant for Next Experience based transactions. One tricky thing is that, in Next Experience, the URL names are not as self-explanatory as they were with previous UI versions. For example, in the Core UI transactions have URLs like /incident.do for the incident form, and /incident_list.do for opening a list of incident records. On the other hand, most transactions in Next Experience have URLs like /api/now/par/pardata, /api/now/graphql or /api/now/batch. In order to understand more about what each of these do, you need to use additional tools like the following: Inspect the Node Logs.Use a client-side tool like NED Tools or Chrome Developer ToolsEnable ServiceNow Session Debugging that will output more details to the UI. One helpful feature of Client Interactions is that at the bottom of each Client Interaction form, there is a Related List that includes most, if not all, of the related Transaction Log records for that Interaction. For a description of Transaction Log fields and how they work, see "Troubleshooting Guide: Using the Transaction Logs" https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0584420 Also, as mentioned earlier, for a video on how to use the logs, see "How to troubleshoot a slow transaction" https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0997495 You will want to personalize your list view of the Slow Transactions table. Here is an example of some helpful fields you may want to add: The following diagram shows some of the events from the PerformanceResourceTiming API that ServiceNow observes to calculate client transaction timings. NED Tools (Next Experience Developer Tools) NED Tools, previously known as Seismic Developer Tools, is your Swiss army knife for troubleshooting any type of Next Experience issue. Most notably, it has an "Inspector" feature and a "Profiler" feature. The "Inspector" allows you to drill down to the specific Components in the UI and see their real-time related Properties, Actions and Transactions. The "Profiler" allows you to record, save and compare a period of Next Experience activity. Troubleshooting Scenarios with NED Tools - KB1543474 (covers Analyzing Performance with Flamecharts, Comparing with the Profiles Pane and much more)https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1543474 User Manual in ServiceNow Dev sitehttps://developer.servicenow.com/dev.do#!/reference/next-experience/latest/developer-tools/using-next-experience-developer-tools Next Experience Developer Tools Release Notes on ServiceNow Doc sitehttps://docs.servicenow.com/csh?topicname=nedt-rn.html&version=latest