Study guide
8.3 Configuring Automatic Lookups
Splunk Core Certified User Study Guide Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts & Logistics 1.2 Study Strategy & Learning Path
2 Splunk Basics
2.1 Splunk Components 2.2 Uses of Splunk 2.3 Splunk Apps 2.4 User Settings & Basic Navigation
3 Basic Searching
3.1 Running Basic Searches 3.2 Setting Time Ranges 3.3 Contents of Search Results 3.4 Refining Searches 3.5 Using the Timeline 3.6 Working with Events 3.7 Controlling Search Jobs 3.8 Saving Search Results
4 Using Fields in Searches
4.1 Understanding Fields 4.2 Using Fields in Searches 4.3 The Fields Sidebar
5 Search Language Fundamentals
5.1 Basic Search Commands & Practices 5.2 The Search Pipeline 5.3 Specifying Indexes in Searches 5.4 table, rename, fields, dedup, and sort
6 Using Basic Transforming Commands
6.1 The top Command 6.2 The rare Command 6.3 The stats Command
7 Creating Reports and Dashboards
7.1 Saving and Editing Reports 7.2 Statistical Table Reports 7.3 Chart Visualization Reports 7.4 Creating Dashboards and Adding Reports 7.5 Editing Dashboards
8 Creating and Using Lookups
8.1 Lookup Concepts and File Examples 8.2 Creating Lookup Files and Definitions 8.3 Configuring Automatic Lookups 8.4 Using Lookups in Searches
9 Creating Scheduled Reports and Alerts
9.1 Scheduled Reports 9.2 Describing and Creating Alerts 9.3 Viewing Fired Alerts
8.3 Configuring Automatic Lookups
Key Takeaways Explain This Topic AI
An automatic lookup applies a lookup definition at search time for events that match the configured sourcetype, source, and/or host constraints.
Automatic lookups map input fields (event fields) to lookup key fields and define which enrichment fields are added to events.
After an automatic lookup is configured and permitted, users often get enrichment fields without typing | lookup in every search.
Field-name matching must be correct: the event field used as input must align with the lookup's key values.
Last updated: August 2026
Apply a lookup without typing | lookup every time
Topic 7.4 covers automatic lookups . Once you have a lookup definition, you can configure Splunk to apply it automatically for events that meet certain criteria. That means many searches — reports, dashboards, ad hoc investigations — can receive enrichment fields without repeating the | lookup command.
Automatic lookups still happen at search time . They are a convenience and consistency layer on top of the same matching idea: find the row for a key, add enrichment columns.
Where to configure them
Path: Settings > Lookups > Automatic lookups → Add new .
You will associate:
- A lookup definition (the named CSV/file-based lookup you already created)
- Apply-to constraints such as sourcetype , source , and/or host
- Field mappings for inputs (match) and outputs (enrichment)
- Apply to sourcetype, source, or host
Automatic lookups are scoped. You decide which events should trigger the lookup.
- Apply-to field Example Meaning
- sourcetype access_combined Apply when events have that sourcetype
- source /var/log/httpd/access_log Apply for that source value
- host web01.example.com Apply for that host
You can use these constraints to avoid enriching unrelated data. A status-code lookup for web logs should not necessarily run against every sourcetype in the deployment.
Exam focus: Know that automatic lookups are configured against lookup definitions and can be limited by sourcetype / source / host style criteria.
Fields must match
Automatic lookup configuration includes mapping between:
- Input fields — fields in the events used as lookup keys
- Lookup fields — corresponding key columns in the lookup table
- Output fields — enrichment columns from the lookup that should be added to events (optionally renamed)
Example mapping for http_status :
- Role Event / output side Lookup table side
- Match input event field status lookup column status
- Enrichment output event field status_description lookup column status_description
- Enrichment output event field status_type lookup column status_type
If your events store the code in http_status but the CSV key column is named status , the automatic lookup mapping must connect http_status (event) to status (lookup). Wrong field pairing is the most common reason "the automatic lookup does nothing."
What users experience after configuration
Suppose automatic lookup is set for sourcetype=access_combined using definition http_status .
A user runs: sourcetype=access_combined status=503
If permissions allow and mappings are correct, returned events can include status_description and status_type even though the search string never mentioned | lookup . Those fields then appear in the fields sidebar and can be used in follow-on commands: sourcetype=access_combined
| stats count by status_type
Without the automatic lookup (and without a manual | lookup ), status_type would not exist unless it was already extracted from the raw data.
Automatic vs manual | lookup
Approach Pros Watch-outs
Automatic lookup Consistent enrichment; less typing; great for shared web/app data Must scope correctly; field maps must be right; permissions still apply
Manual | lookup Explicit per search; easy to test; useful when only some searches need enrichment Easy to forget; duplicated SPL across reports
For learning and troubleshooting, many analysts still run a manual | lookup first to prove the definition works, then create the automatic lookup for convenience.
Permissions still matter
An automatic lookup is another knowledge object. If it is private to you, teammates may not benefit. If the underlying lookup definition or table file is not readable, automatic enrichment can fail for others. When a scenario says "only some users see the extra fields," think permissions and app context again.
Practical configuration checklist
Confirm the lookup definition works with a manual | lookup test search.
Open Settings > Lookups > Automatic lookups .
Select the definition.
Set sourcetype/source/host constraints appropriate to the data.
Map input fields carefully (event field ↔ lookup key).
Choose output fields to add.
Set permissions .
Re-run a simple search against matching events and verify enrichment fields appear.
Exam traps
Trap: Believing automatic lookups rewrite indexed historical raw data. They enrich at search time for matching searches.
Trap: Configuring automatic lookup but mapping the wrong input field name — no matches, no enrichment.
Trap: Applying an automatic lookup too broadly (wrong sourcetype) and wondering why unrelated events get unexpected fields — or why the intended events do not.
Trap: Forgetting that automatic lookups depend on an existing lookup definition (and usually an uploaded CSV for User scenarios).
Bottom line for topic 7.4
Automatic lookups = "Always apply this definition to these kinds of events, using these field maps." Master the Settings path, the sourcetype/source/host scope, and the requirement that match fields align between events and the lookup table.
Naming and organization tips
Give automatic lookups clear names that show both the definition and the scope, such as access_combined_http_status . Clear naming helps when multiple automatic lookups exist in an app and when exam scenarios ask which object applies to a sourcetype.
Keep one automatic lookup focused on one enrichment job. If you later need a second enrichment (for example user ID to department), create another automatic lookup with its own definition and field maps rather than overloading a single confusing configuration.
Verifying enrichment in the UI
After saving, run a narrow search against matching events and confirm:
- New enrichment fields appear in the fields sidebar
- Values make sense for known keys (for example 404 → Not Found )
- Non-matching events simply lack enrichment values instead of breaking the search
- A search against a different sourcetype does not unexpectedly receive the same fields (scope is working)
If enrichment appears only for you, revisit permissions on the automatic lookup and its underlying definition/file.
Relationship to search pipelines
Automatic lookups enrich events during search-time processing for matching host/source/sourcetype streams. Downstream commands in the same pipeline can immediately use those fields. That is why a dashboard panel search can chart status_type even when the original log line never contained that string — as long as the automatic lookup (or an explicit | lookup ) supplied it.