I85PREP
⌘ K
Splunk Core Certified User study materials
Splunk Core Certified User study resources

The Dashboard Dana Cannot See

Splunk Core Certified User · Put your knowledge to work in context.

All case studies

The Dashboard Dana Cannot See

Dana joins the payments operations team. Her colleague Miguel shows her a 'Payments Ops' dashboard in Splunk Web. When Dana logs in, the dashboard is not in her list, even though she can type the underlying searches into the Search bar and get results. On those searches, Miguel's results include a field called card_type, while Dana's identical search on the same sourcetype shows cardType. Separately, Dana runs index=payments sourcetype=txn | stats count with the time range set to Last 24 hours and gets zero results, but the same search over All time returns 4.2 million events.

1. The dashboard is shared at app level in the Payments app. What has to be true about Dana's account for it to appear, and what would you check first?

Read the worked answer

App-level sharing means the object is visible to roles that have read access to that app. Two things must line up:

  1. Dana's role must be granted access to the Payments app (Settings > Roles > [role] > Apps, or the app's own permissions page). A user only sees apps their roles can read; the dashboard inherits the app's visibility unless it was individually restricted.
  2. The dashboard's own permissions must include Dana's role - a knowledge object can be shared at app level but still list only specific roles.

Check order: open the dashboard's Edit > Permissions to see which roles have read, then open Dana's role definition to see whether that role is even assigned to her and whether the Payments app is listed for it. Also confirm she is not simply in a different app context - the app name is shown next to the search bar, and the dashboards listed are those of the current app.

Miguel being able to see it proves nothing about Dana: permissions are evaluated per user through roles, not per team.

2. Give two plausible reasons why Dana sees `cardType` and Miguel sees `card_type` for the same sourcetype, and describe how you would confirm which one it is.

Read the worked answer

Two realistic explanations:

  • Different app context. Field extractions, field aliases, calculated fields and tags are all scoped to an app. If Miguel is in the Payments app and Dana is in Search & Reporting, an app-scoped alias mapping cardType to card_type (or an app-scoped regex extraction) applies to him and not to her.
  • Different sourcetype. The same data can be indexed under two sourcetype names (for example if one path sets it explicitly and another relies on auto-detection), and each sourcetype can carry its own extraction. cardType is a classic JSON/key-value raw field name; card_type looks like an alias or a renamed extraction.

How to confirm: in both searches, add | head 1 and look at the sourcetype and the app name shown in the UI, then run | fieldsummary or check Settings > Fields > Field aliases and Field extractions filtered by that app and sourcetype. If the raw event contains cardType, the difference is an alias or calculated field; if it contains card_type, the difference is the sourcetype/extraction.

A quick tiebreaker: set both searches to the same app and compare again. If they converge, the cause was app context.

3. Why would `index=payments sourcetype=txn` return zero events in the last 24 hours but 4.2 million over All time? What is the most likely cause, and how do you verify it?

Read the worked answer

The search itself is fine; the events are not landing where Dana thinks they are in time. Relative time ranges filter on the event _time, which is the timestamp Splunk parsed from the event (falling back to file modification time or index time when parsing fails).

Most likely causes:

  • Backfilled data - the 4.2M events were loaded with _time values from weeks or months ago, so none fall in the last 24 hours.
  • Timestamp misparsing - the sourcetype's TIME_FORMAT/SHOULD_LINEFORMAT/timezone settings do not match the raw format, or the events carry a timezone Splunk assumes wrong, shifting _time by hours or days.
  • Ingest stopped - the feed has been dead and the newest event is older than 24 hours.

Verify with a single search:

index=payments sourcetype=txn
| stats count min(_time) as first max(_time) as last
| eval first=strftime(first,"%F %T"), last=strftime(last,"%F %T")

If last is days old, check the input and splunkd.log for forwarder disconnects. If last is current but first is far in the past, the data is backfilled. If the times look scrambled relative to the raw event text, it is a timestamp parsing problem in props.conf for that sourcetype - and the fix belongs in configuration, not in Dana's search.