Splunk Enterprise Security

Configured Detections Have Disappeared from All Automation Rules

shenglc
New Member

Hello

I'm experiencing an issue with Automation Rules in Splunk Enterprise Security (8.5.1). Sometimes I'm able to add a detection successfully, but after saving, other previously configured detections disappear. In other cases, I receive the following error:


"Could not update automation rule: Failed to create automation rule mapping as detection is already mapped to an automation rule."

What's confusing is that after this happens, some of the detections I had added previously are no longer visible in the rule. The behavior seems inconsistent, as sometimes detections can be added and other times they disappear or trigger the error above.

Labels (1)
0 Karma

natecrisler
Path Finder

Hey shenglc — there are two things tangled together here: one is expected behavior, the other looks like a bug.

The error first. In ES 8.x a detection can only be mapped to one automation rule at a time — On or Off doesn't matter. So "Failed to create automation rule mapping as detection is already mapped to an automation rule" means that detection is already attached to another rule (or a stale mapping for it exists). To move it, remove it from the rule that currently owns it, save, then add it to the new one. Quick way to find where it lives: open the detection itself (Edit event-based / finding-based detection) — the Details section names the automation rule it's tied to.

A second thing that can make detections "vanish": every detection in a rule has to be status = On. If detection versioning is on and a save spins up a new version that isn't enabled (new versions don't auto-turn-on), or a detection otherwise flips off, it drops out of the rule's valid set. Worth confirming all your mapped detections are still On and you're not looking at a superseded, disabled version.

Now the part that isn't expected: previously-saved detections disappearing when you add a new one. The 8.5 UI is supposed to gray out detections already used elsewhere so you can't even pick them — so hitting the "already mapped" error and losing other detections on save looks like the mapping save is partially failing and rewriting the rule with a subset instead of cleanly rejecting just the conflicting detection. That's not something you can config around.

Practically:

  • Edit one detection at a time, save, then re-open the rule to confirm the list actually persisted before adding the next. Avoid two tabs or two admins editing at once.
  • Before adding any detection, check its detail page to confirm it isn't already mapped elsewhere, and remove it there first if it is.
  • If a detection shows as "already mapped" but you can't find which rule owns it, that's an orphaned mapping — Support needs to clean that one up.
  • Check the 8.5.x release notes and known issues, and since this reproduces, open a Splunk Support case with exact repro steps. There have already been automation-rule regressions reported across the 8.x upgrades, so it's worth putting in front of them directly.

Doc: Configure automation rules (ES 8.5)

Couple things to narrow it down: are the detections that disappear ones you'd also added (or tried to add) to a different rule, and do you have detection versioning turned on?

0 Karma
Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

From Data to Insight: Announcing the Winners of the Splunk Dashboard Contest

Hi Splunkers, First off, thank you to everyone who participated in our very first From Data to Insight: The ...

Splunk Developers: Construct Your Future at the .conf26 Builder Bar

Calling all Splunk architects, platform admins, and app developers: the site is open, and the blueprints are ...

Quick connection discovery mode for forwarders

When a Splunk forwarder loses connectivity to its indexers, it does not always reconnect immediately. In many ...