Knowledge Objects: Tags, Event Types, Lookups, and Workflow Actions
Shared, permissioned configuration
Knowledge objects are reusable configurations stored in an app context with private or shared (app/global) permissions. If another user cannot see your tag or lookup, permissions are almost always the answer.
Tags
A tag names a specific field/value pair - for example tagging sourcetype=access_combined as web. Search it like a field: tag=web, or combine tag=web tag=error. Tags exist only at search time and never alter indexed data.
Event types
An event type is a saved search whose matching events gain the field eventtype. Search eventtype=login_failure; list them with | eventtype. Event types can be tagged, assigned a priority, and reused by alerts and other knowledge objects.
Lookups
Lookups join external data at search time. A lookup definition (transforms.conf) points at a CSV file or a KV Store collection; an automatic lookup is wired to a sourcetype in props.conf and runs on every event, so keep those small. Commands: | lookup file.csv key OUTPUTNEW newfield, inputlookup to read a whole table, outputlookup to write results back. OUTPUT overwrites existing fields; OUTPUTNEW only fills fields that do not already exist - a favorite exam trap.
Workflow actions
Workflow actions add links or POSTs to the event Actions menu. They are configured as GET, POST, or search, may reference event values with $field$ tokens, can be restricted by app and role, and appear only when the triggering field has a value in that event.
Worked example:
index=sales | lookup products.csv product_id OUTPUTNEW product_name
Enriches events without clobbering a product_name that extraction already produced.
Rule of thumb: default to OUTPUTNEW unless you deliberately want to overwrite existing values.