How to Share a Report in Splunk

Learn how to change Splunk report permissions, choose app or all-apps sharing, assign role-based read and write access, and validate report availability.

A Splunk report is a saved search intended for reuse, reporting, scheduling, or display. It stores the search definition along with reporting-oriented settings and can be run by authorized users.

Reports are knowledge objects. A knowledge object is a Splunk object, such as a saved search or report, that has an owner, sharing scope, and role-based permissions. These settings determine who can discover, run, and modify the report.

Default visibility of a new report

Newly created reports are private by default. A private report is visible and editable only by its owner unless an administrator or another authorized user changes its permissions.

The owner is the user account associated with the knowledge object. Private access protects a report while it is being developed, but it also prevents colleagues from finding or running it.

Open a report's permission settings

In Splunk Web, open Settings.
Select Searches, reports, and alerts.
Locate the report you want to share. Use the app, owner, or search controls if the list is large.
Open the report's Permissions action.
Choose a sharing scope and assign read and write permissions to roles.
Select Save to apply the changes.

Settings > Searches, reports, and alerts
Find the report
Open Permissions
Choose sharing scope
Assign read and write roles
Save

The exact placement of an action can vary slightly by Splunk version or app, but the report management page is the standard place to change these settings. No SPL command is required when using the standard Splunk Web interface.

Understand report sharing scope

Sharing scope controls where a report is available. It is separate from role permissions: the scope determines the app area in which the object can be discovered, while roles determine which users can use or modify it.

Sharing setting	Who can discover or use the report	Recommended use case	Important limitation
Private	Only the owner	Drafts, personal analysis, or reports still under development	Other users cannot use the report until its permissions change
This app only	Authorized roles in the selected app context	Reports intended for one team's app or a specific operational workflow	The report may not appear when users work in another app
All apps	Authorized roles across Splunk apps	Organization-wide reports or shared content used across multiple apps	Cross-app visibility does not grant access to the report's data or dependencies

App-level sharing

Choose This app only when the report belongs to one app, one team, or one workflow. App-level sharing reduces unnecessary cross-app visibility and makes it easier to keep related content together.

For example, a report used only by an operations team can remain in that team's app. Grant read access to the roles that use the app rather than exposing the report throughout Splunk.

All-apps sharing

Choose All apps when users need to find and use the report from more than one app. This is appropriate for standardized management, compliance, or service reports that are intentionally shared across teams.

All-apps sharing does not bypass authorization. Users still need access to the relevant app context, indexes, data sources, and dependent knowledge objects. A report can be visible while its search returns no data for a user who lacks the required data access.

Assign role-based permissions

A role is a Splunk authorization grouping used to grant capabilities and access. Report permissions are assigned to roles, not directly to individual users. A user's effective access comes from the roles assigned to that user.

Permission	What the role can do	Typical roles	Risk level
Read	View, discover, and run the report	Viewer, analyst, reporting team, or Everyone	Lower risk, although the search may expose results the role is already authorized to see
Write	Modify the report definition and its settings	Owner, report maintainers, trusted administrators	Higher risk because changes affect every user of the shared report

Read permission

Read permission allows a role to view and use a report. A user with read access can generally discover the report in the appropriate app context and run it, subject to data and dependent-object authorization.

The built-in Everyone role is commonly used for broad read-only availability. Assigning read access to Everyone makes the report available to all users covered by that role, but it does not give those users write access.

Write permission

Write permission allows a role to modify the report definition and settings. Write access should normally remain with the owner, designated content maintainers, or trusted administrators.

Do not grant broad write access simply because many people need to run a report. Grant write permission to a reporting team only when collaborative maintenance is an intentional requirement.

Example: make a report available to all users

Open Settings > Searches, reports, and alerts.
Find the target report and open Permissions.
Set the sharing scope to All apps.
Assign Read permission to the Everyone role.
Keep Write permission limited to the owner, trusted administrators, or an approved report-maintainer role.
Save the permission changes.
Test the report with a standard user account or representative role.

Example: share a report with one app

Open the report's permission settings from the searches, reports, and alerts list.
Choose This app only.
Grant read access only to roles that use the app.
Grant write access only to the report owner or the designated app-maintainer role.
Save and confirm that users can find the report within the intended app.

This approach limits unnecessary cross-app visibility while still allowing the relevant team to use the report.

Example: allow a reporting team to maintain a report

Choose the appropriate app scope, such as This app only for team-specific content or All apps for organization-wide content.
Grant the reporting team role Read permission.
Grant that same role Write permission only if its members are responsible for maintaining the report.
Keep general viewer roles read-only.
Test with a reporting-team member and with a general viewer.

The team member should be able to edit the report, while the general viewer should be able to run it without changing its definition.

Validate sharing after saving

Sign in as a non-owner or use a test account representing the intended role.
Open the expected app context and confirm that the report appears in the relevant report or search list.
Run the report and verify that it returns results appropriate for that role.
Attempt an edit with the test account. A read-only user should not be able to modify the report.
Test with a designated maintainer if write access was granted.
Check more than one app when the report was shared with All apps.

Validation should cover both object access and search execution. Seeing a report in a list does not prove that the user's role can read every index, lookup, macro, data model, or other object used by the search.

Security and governance considerations

Use least privilege: share a report only with the roles and app contexts that need it.
Prefer read-only access for viewers.
Avoid broad write access unless collaborative editing is required and governed.
Review the report's SPL, indexes, macros, lookups, data models, and other dependencies before broad sharing.
Confirm that the intended audience is authorized to access the underlying data.
Remember that report visibility does not automatically grant permission to restricted data.
Use an owner or named maintainer role so users know who is responsible for changes.
Periodically review shared reports and remove obsolete roles or unnecessary all-apps visibility.

Troubleshooting report sharing

Another user cannot find the shared report

The report may still be private.
It may have been shared only within a different app.
The user's role may not have read permission.
The user may be searching from an app context where the report is unavailable.

Review the sharing scope, confirm read access for the user's assigned roles, and check the app context used by the affected user.

A user can see the report but cannot edit it

The role probably has read permission but not write permission. This may be intentional. Grant write access only when collaborative maintenance is required; otherwise, retain read-only access and use an approved change process.

The report runs but returns no results for some users

The users may lack access to the indexes or data referenced by the report.
The report may depend on restricted lookups, macros, data models, or other knowledge objects.
Role-specific search restrictions may affect the results.

Test with the affected role, validate data and dependent-object permissions, and adjust authorization only when appropriate. A shared report should not be used to circumvent data-access controls.

The report appears in one app but not another

The report may be shared at app scope rather than with All apps. The target app may also have its own visibility or navigation constraints. Change the scope to All apps when cross-app availability is intended, then confirm that the report is being accessed through a permitted app context.

Key points

A report is a saved search and a Splunk knowledge object.
New reports are private by default.
This app only limits availability to one app context; All apps supports cross-app availability.
Read permission controls viewing and running; write permission controls modification.
Permissions are assigned to roles, and Everyone can provide broad read-only access.
Sharing a report does not grant access to restricted indexes or dependent objects.
Always validate discovery, execution, and editing behavior with representative roles.

For related tasks, see Reports Overview, Alerts Overview, Create an Alert, and Create a Report.