After updating a dashboard in myApp, a Splunk admin moves myApp to a different Splunk instance. After logging in to the new instance, the dashboard…

There are three primary reasons why the dashboard might not be visible on the new instance. First, if the dashboard's permissions were set to "Private," it would be saved in the user's specific directory (etc/users//myApp/local), not the app's main directory (etc/apps/myApp/). Consequently, it would not be included when the app is packaged and moved. Second, deleting the myApp/local directory before packaging would discard all UI-driven changes and customizations, including the updated dashboard. Finally, even if the dashboard is moved correctly, the user's role on the new instance might lack the necessary permissions to view objects within myApp, making the dashboard invisible to that user.

D. This path points to the default navigation file for the Search & Reporting app, not a dashboard view within myApp. Changes to a dashboard in myApp would not be saved here.

1. For Answer A: Splunk Enterprise Documentation

Knowledge Manager Manual

"Manage knowledge object permissions". This section explains that private objects are user-and-app-specific and are not available to other users. It also details that these configurations are stored in $SPLUNKHOME/etc/users///local

which is outside the standard app directory ($SPLUNKHOME/etc/apps/) used for packaging.

2. For Answer C: Splunk Enterprise Documentation

Admin Manual

"Configuration file directories". This document outlines the configuration file system

stating that user-level changes made through Splunk Web are saved in local directories. Deleting the local directory within an app effectively reverts it to its default state

removing any customizations.

3. For Answer B: Splunk Enterprise Documentation

Securing Splunk Enterprise

"About users and roles". This manual describes how roles define a user's access to Splunk resources. A user's role must grant read access to an app and its knowledge objects for them to be visible. If the user's role on the new instance is configured differently

access can be denied.