7.1 Saving and Editing Reports

7.1 Saving and Editing Reports

Domain 6.0 Creating Reports and Dashboards is about 12% of the Splunk Core Certified User exam. Objectives 6.1 and 6.2 sit at the front of that domain: turn a useful search into a report, then keep that report accurate as needs change. This is how Users move from one-off exploration to reusable analysis others can open from the Reports listing—or later embed on a dashboard.

If you remember one framing: a report is a saved search definition plus the display choices you set (table, chart type, and related formatting). It is not just a screenshot of today's results.

Why Save as a Report?

After you refine a search with fields, time ranges, and transforming commands (stats, top, rare, and similar), you often want to:

• Rerun the same analysis tomorrow without rewriting SPL
• Share a named, documented search with teammates in the same app
• Use that saved search as a dashboard panel (covered in 7.4)
• Optionally schedule delivery later (Domain 8.0—mentioned only lightly here)

Saving as a report locks in the search string, time range context, and visualization/formatting so the next open is consistent.

Save As Report Workflow (Objective 6.1)

Typical User-level path from Search:

1. Run a search that returns useful Statistics or Visualization results.
2. Confirm the time range and formatting you want preserved.
3. Choose Save As → Report (wording may vary slightly by Splunk version/UI).
4. Enter a clear Title and optional Description.
5. Decide initial Permissions (usually leave Private until you are ready to share).
6. Confirm creation, then open the report from the confirmation dialog or the Reports page.

What gets saved

When you open the report later, Splunk reruns the search (subject to schedule/acceleration settings outside this section’s focus) and shows fresh results for the configured time window.

Worked example: save a stats report

index=web sourcetype=access_combined status=5*
| stats count by status, host
| sort - count

After the Statistics tab looks right, save as report titled Web 5xx Counts by Host. Description: “Server-error volume by host for ops triage.” Leave permissions Private while you validate. That single action completes objective 6.1 in practice.

Report Permissions Basics

Any report you create is initially private—visible and editable by you. If your role allows, you can share it.

Within a shared context, permissions usually distinguish Read (open and run) from Write (edit definition). Default User roles commonly create private reports; Power and Admin roles more often share to the app and set role-based access. On the exam, know the default privacy rule and that sharing is intentional—not automatic.

You can set permissions:

• Immediately after creation via the “report created” dialog
• From Edit → Edit Permissions on the report
• From the Reports listing page
• From Settings → Searches, Reports, and Alerts (when available to your role)

Display / run-as context (light awareness)

Shared reports can run with Owner or User context. Owner context uses the creator’s search permissions when others open the report; User context uses the viewer’s permissions. For User prep, recognize that permissions include both who can open the report and whose data access applies when it runs—without diving into admin policy design.

Editing Reports (Objective 6.2)

Editing keeps a report current when the SPL, time window, or chart choice needs to change.

Common edit entry points:

• Open the report → Edit
• Reports listing → Edit on the row
• Settings list of searches/reports/alerts → Permissions or edit links

Edit search and visualization

Two high-yield edits:

1. Edit the search — Open the report’s search, change SPL, rerun, and save. Example: extend status=500 to status=5* after ops asks for all server errors.
2. Edit the visualization — On Visualization, use the Visualization Picker (Table, Column, Line, Pie, and so on), adjust axes/legend as needed, then save so the next open shows the new chart type.

Pivot-based reports exist in Splunk, but User blueprint focus is search-built reports: save from Search, edit search/viz, manage basic permissions.

Schedule: know it exists, do not overstudy here

From Edit you may see schedule options (run on a cron-like interval, email results). For Domain 6, treat scheduling as awareness only. Domain 8.0 Creating Scheduled Reports and Alerts owns configure-and-describe depth. Distractors that demand throttle windows, real-time alert triggers, or acceleration settings belong elsewhere.

Reports Listing Page Habits

Use the Reports page to:

• Find reports by name
• Open, clone, edit, or set permissions
• Confirm whether a report is private or shared
• Jump into a report before adding it to a dashboard

Clone is useful when you want a variant without destroying the original—for example cloning Web 5xx Counts by Host into Web 5xx Counts by Host - Weekly with a longer time range.

Exam Traps for 6.1 and 6.2

Why This Matters on the Exam

Expect scenario questions like:

• You built a useful stats search—what do you do so others in the Search app can open it by name?
• A report’s pie chart should be a column chart—what do you edit?
• A report is missing from a coworker’s Reports list—what permission state is most likely?

Correct answers emphasize Save As Report, Private by default, share to App, and Edit for search or visualization—not macros, CIM, or Studio drilldowns.