A Little More Logic in Splunk: Introducing SPL2’s if Command

If you have spent enough time writing SPL (10y here!), you have probably run into a familiar situation: you want to process events differently depending on what they contain.

In a typical SPL pipeline, commands are executed sequentially, and filtering commands such as where and search can reduce the number of events passed to subsequent commands.

Maybe you want to enrich events conditionally, or apply different transformations based on a field value. In classic SPL, you can often get the job done with eval, if(), case().

That works, but what if you want to control which block of code gets executed based on a field's value, just as you would in a procedural programming language?

Enter SPL2's if command.

How does it work?

The SPL2 if command was announced for Splunk Cloud Platform version 10.5.2605 on June 29, 2026, but I only became aware of it after seeing this LinkedIn post from Mikael Bjerkeland:

SPL vs. SPL2: what actually changes?

One important distinction: SPL already has an if() function. You do not need SPL2 to write conditional expressions.

In classic SPL, you might use:

| eval severity=if(status>=500, "high", "medium")

| eval severity=if(status>=500, "high", "medium")

The SPL above evaluates a condition and returns one of two values. For several conditions, you might use case()function. This is present in pretty much any modern piped language, including KQL.

SPL2's if command works differently. Instead of using conditional logic only to calculate a value via eval, it lets you define different processing paths directly in your search.

In other words: you can control which SPL2 statements or code blocks are executed based on a condition.

It is a small feature, but one that can make certain searches more powerful.

A real use case: to enrich or not to enrich?

If you have ever worked with events containing network IP addresses, you probably know about the challenges of enriching them with geolocation.

The problem becomes more significant in a large enterprise environment, where network traffic comes from all over the globe.

In Splunk there's a command called iplocation which allows users to enrich the IP address value with its corresponding geolocation data (country, latitude, etc).

This has become important enough that many vendors now include this enrichment in their logs. That's the case for Azure/Entra Sign In logs.

The logs contain a field called location that holds a two-letter country code linked to the IP origin.

However, for whatever reason, not every IP address gets enriched, as you can see below:

So, what's the solution here? Enrich it yourself, right?

The issue is that if you decide to fill the gap (location = Unknown) with enriched data returning from the iplocation command, you need to do it for every single IP address, not only for the unknown ones.

In SPL, that would look like this:

As you can imagine, looking up the geolocation of every IP address can become expensive, depending on the use case (hunting, reporting, etc.) and the event volume (or lookback period). The query may end up running much more slowly than necessary.

The SPL2 solution

With the if command, users can run iplocation only on events where the location field is empty (condition).

Based on the example, the SPL2 code equivalent would look like this:

A few notes here:

• This is a common demand, especially when pivoting to ASN hunting to reveal threat actor infrastructure from a specific location.
• The iplocation command doesn't produce a two-letter country code, but you can enrich or normalize the result later using public lists.
• If you leverage Data Engineering or Data Pipelines, it's worth enriching critical data sources such as Entra ID at ingestion time.

Closing: is that a big deal?

I haven't had much time to explore this further, but I'm sure I'll come across other use cases. For now, I wanted to share this with the community and hear what others think.

That's likely not the best example, but perhaps better than the one in the reference docs which can be easily done using SPL's eval…

A few more interesting examples:

To be transparent, I rarely use SPL2, and I suspect many detection engineers and threat hunters are in the same boat. However, some of its features can be particularly useful in specific scenarios.

There are pros and cons to using it that deserve a deeper discussion, so perhaps I'll explore those in a future article.

Don't forget to subscribe and follow me to get notified about new stories!