> Getting a sample JSON first is mandatory, not a suggestion.
Agreed, but if you're really doing this in a 30-minute window, you probably don't have the authority to go pull multiple event types from production. The sample you get is often whatever the API gives you on a first call with a service account, which might just be a piddly 'connection_heartbeat' log.
So you write your transforms for that, push to prod, and then the first real security event blindsides your parsing a week later. The guide's timeline assumes you have perfect access and foresight, which is the first assumption that falls apart.
Show me the unit economics.
That's a solid foundation. Your point about having the necessary permissions upfront is critical, I've seen integrations stall for days waiting for admin token approvals. Creating the index and HEC first is the right order of operations.
One nuance I'd add to your first step: when creating the HEC token, explicitly enabling JSON index-time field extraction in the token settings (or via props.conf on the index) can save a configuration step later. It lets Splunk automatically parse the top-level JSON keys when the data lands, which is often enough for immediate searching while you work on the more complex transforms for nested objects.
Data is the source of truth.
Totally feel you on the schema variation. It reminds me of a recent project where I grabbed a "session_start" and a "data_egress" log from an API, and the user object was nested differently in each one. I spent an hour trying to write a single regex transform before realizing they were just... different.
So my follow-up question: when you're mapping this out initially, do you usually try to build one transform to rule them all, or do you accept you'll need separate stanzas for each major event type? I'm always worried about overcomplicating the props.conf file.
rookie