Shaping Results: fields, table, sort, dedup
What is it?
After selecting events, you shape them: `table` picks the columns to show, `fields` keeps/drops fields, `sort` orders rows, and `dedup` keeps one row per repeated value. These turn a raw event dump into a readable answer.
Why it matters
An investigation is only as good as its evidence table. Showing the right columns in the right order — and collapsing duplicates — is what lets you (and the next analyst) read the story at a glance.
Where you see it
`... | table _time, user, src, result | sort _time` produces a clean timeline. `... | dedup user | table user, last_seen` shows each user once.
What normal looks like
A good result table has few, meaningful columns, is sorted by time or by the metric you care about, and shows one row per entity when you deduped.
What suspicious looks like
Not the table — but be careful: `dedup` hides rows. If you dedup by user you can no longer count how many times each acted. Shape for the question you are answering.
How analysts investigate
Decide the columns that answer the question, `table` them, `sort` by time or the key metric, and `dedup` only when you truly want one row per entity — not when you still need the counts.
Common beginner mistakes
- Using dedup when you actually needed a count — you lose the very frequency the investigation depends on.
- Tabling twenty columns so the real evidence is lost in clutter.
From event dump to evidence table
sourcetype=auth user=a.hakim
| table _time, user, src, result ← choose the columns
| sort _time ← time order = a readable timeline
result:
_time user src result
02:11:04 a.hakim 203.0.113.44 failure
02:11:15 a.hakim 203.0.113.44 success ← the failed-then-in story, at a glanceQuick check
You want a clean, time-ordered timeline of one account's activity. Which pipeline?
A quick self-check — it doesn't affect your XP or progress.
Sign in to save your progress on the server.