What is a Dashboard? 

In the collaborative work management space, a dashboard in the simplest terms is a comprehensive visual display of relevant data for a team, department, or company. Dashboards provide a glance at the who, what, where, when, and why of business operations. The data displayed in dashboards contains metrics and analytics, key performance indicators (KPI’s), reporting, and other widgets on a single screen. Users can utilize dashboards to gain insight into the critical functions and work within and across teams and departments (i.e., types of work assigned, status of work from conception to completion, who is responsible for delegated work/tasks, due dates, etc.).  

With the ServiceNow® Dashboards product, multiple performance analytics, reporting, and other widgets are displayed and viewed on a single screen. They provide visibility and transparency needed for team leaders and key decision makers by enabling them to monitor what work is getting done and identify where bottlenecks are impacting productivity. ServiceNow dashboards are highly customizable and can be adjusted to individual users’ specific needs whether they are knowledge workers, managers, or C-Suite executives. As a result, our dashboards are among the most popular and visible features the Now platform custom application offers.  If there is a problem with one of our dashboards, our clients will notice quickly and it will impact the perception of quality for the product. 

Unfortunately, a crucial limitation with ServiceNow dashboards is portability. Deploying dashboards between environments can be a smooth process, but it can also lead to many hours of stress and lost productivity. This is because of inconsistencies caused by minor changes applied to an existing dashboard that is subsequently redeployed. 

The Challenge of Dashboard Migration  

The crux of the issue with migrating dashboards in ServiceNow is being able to reliably move dashboards from one ServiceNow instance, server, or environment to another (i.e., moving it through from development to testing, staging, and production), especially if you deploy the same dashboard repeatedly. If you repeatedly deploy one dashboard from one instance to another, the deployment becomes less and less reliable over time. To make matters more challenging, in secure environments (and other environments following best practices) developers are likely unable to access the production environment—except for Development or Sandbox environments—to fix observable issues and bugs. Therefore, update sets are utilized to deploy dashboards from lower environments to higher environments.  

Custom application developers who utilize code hosting platforms, such as GitHub (GIT), for version control and collaboration to maintain and update their applications also run into problems with dashboard migration. For example, issues arise when application developers make their applications available on the ServiceNow app store. When dashboards on the reference system are updated and deployed to GIT, it does not necessarily mean that the updates made are present in the code base.  Many instances have occurred where dashboard updates made in the GIT repository were not present when deploying the latest code to a new server. This results in delayed timelines because it prevents developers from making their applications available on the store until the issue is resolved. Countless manhours are expended when a dashboard deployment issue is identified, and resolution is attempted. 

What Is the Root Cause of These Issues?  

Dashboards are typically built in an environment where data is available to effectively report on and visualize key data sets.  Most dashboards are built in Production environments by a variety of end users.  It is likely that portability was not considered a priority as a result in the ServiceNow dashboard’s original implementation.   

The root cause of dashboard portability challenges is that when dashboards are updated regularly and exist in multiple environments, the underlying data structure gets out of sync.  Many ServiceNow users expect the dashboard packaging mechanism provided by ServiceNow to translate a dashboard layout into an Update Set, called Unload Dashboard, to work every time.  In practice, this is not the case.  The underlying data structure that represents the dashboard layout gets out of sync and any changes you make in one environment will not be accurately displayed in the target environment.   

A common issue is that the dashboard tabs do not deploy properly.  When looking at the Tab form, a Page field should be populated when validating tabs have been moved successfully.  If it is not, you have a problem.  You will need to search for the associated portal page and select it.  This can be confusing if you have a common tab name since the tab name is inherited by the portal page.  If the portal page needs to be redeployed, ServiceNow provides a command called Unload Portal Page (see step 8c in the linked article) to help you deploy the missing Portal Page, which you then need to associate with the tab.  In extreme cases, we have had to synchronize each underlying table manually (notably, the Portal Page, Grid Canvas, and Grid Canvas Pane tables). See glossary below. 

The fundamental issue here is that most users (administrators/developers) don’t know they need to check for missing Portal Pages on the Tab form within Dashboard Properties when deploying dashboards.  As a result, this issue is not caught early thereby compounding the problem, and a lot of time is wasted determining the root cause and resolving the issue.