use-cases/detection-deduplication.md

---
name: detection-deduplication
description: Automatically identify and close duplicate Next-Gen SIEM detections by running an Event Query that uses defineTable()/match() to find prior alerts sharing the same underlying events, then tag, comment, and set the duplicate detection to closed while recording the original detection it duplicates
source: CrowdStrike Content Library playbook "Close Duplicate Next-Gen SIEM Detections Automatically" (https://falcon.crowdstrike.com/login/?unilogin=true&next=/content-library/details/global:fusion_playbook:e066f4a1dee649c4965c31f76838cad2)
example: skills/authoring/examples/ngsiem/close-duplicate-detections.yaml
skills: [authoring, deployment, execution]
capabilities: [workflow, event-query, deduplication]
---

## When to Use

User wants to cut alert fatigue by auto-closing Next-Gen SIEM detections that duplicate an earlier
one. This is common when overlapping correlation-rule intervals and search windows cause the same
underlying activity to fire repeatedly (the exact pain called out in the Workflow Wednesday
"NG-SIEM Correlation Rule Alerts" post). The workflow queries the event store for previous alerts
that share the current detection's child event IDs, and if it finds one, it tags, comments, and
closes the duplicate.

This is grounded in the real Content Library playbook
`skills/authoring/examples/ngsiem/close-duplicate-detections.yaml`. Read that file for the full
structure: an NG-SIEM detection trigger, an Event Query (`Inline.QueryEvent`) whose CQL uses
`defineTable()` and `match()` for dedup, a CEL condition on the results, and a sequential loop that
tags/comments/closes each duplicate. Note for Falcon Complete customers: this playbook can limit
detection visibility for the Falcon Complete team; consult your Security Advisor before enabling.

## Pattern

1. **Trigger on the NG-SIEM detection (Signal).** The trigger is `Signal` with
   `event: Investigatable/NGSIEM` and `version_constraint: ~1`.
2. **Create working variables.** "Create variable" (class `CreateVariable`) declares a schema with
   `alerted_before_detections` (array), `is_duplicate_detection` (boolean), and
   `original_detection_id` (string) to carry state through the workflow.
3. **Query for prior alerts with the same events.** The "Duplicate NG-SIEM Detections Query" action
   (`Inline.QueryEvent`, `cdf5c3e0d69f156eaaf56c1f5d3f1b66`, `version_constraint: ~1`) runs against
   `repo_or_view: search-all`. Its CQL builds a lookup of previous detections' child event IDs with
   `defineTable(query={ #repo=xdr_indicatorsrepo | report_name=?detection_name Ngsiem.alert.id!=?detection_id ... | groupBy([Ngsiem.child.event.id], function=collect([alerted_before, previous_alert_id])) }, include=[...], name="previous_detection_event_ids")`,
   then pulls the current detection's events and `match(file="previous_detection_event_ids", field=[Ngsiem.child.event.id], include=[alerted_before, previous_alert_id], strict=false)`
   to flag events already alerted on. `detection_id` and `detection_name` are passed in as query
   args from the trigger.
4. **Condition on a duplicate hit.** A CEL condition checks
   `data['DuplicateNGSIEMDetectionsQuery.results'].size() > 0 && data['DuplicateNGSIEMDetectionsQuery.results'].filter(e, e.alerted_before == true).size() > 0`.
   Only detections with a prior match continue.
5. **Collect the prior alert IDs.** "Update variable" (class `UpdateVariable`) sets
   `alerted_before_detections` by filtering the query results to `alerted_before == true` and
   splitting/deduping the `previous_alert_id` values.
6. **Loop over each duplicate, sequentially.** A `For each alerted_before_detections; Sequentially`
   loop runs a second Event Query, "Get Detection Status" (same `Inline.QueryEvent` id
   `cdf5c3e0d69f156eaaf56c1f5d3f1b66`), to check whether the detection is already closed
   (`last_status != "closed"`), then marks `is_duplicate_detection: true` and records
   `original_detection_id`.
7. **Tag, comment, and close.** On the duplicate branch: "Add tag to alert"
   (`6de8a462880ad419680ed5c291b9413f`) adds a `Duplicate Detection` tag, "Add comment to detection"
   (`7b77cb5d5ff2651cc51c7c4c610d54d1`) records the auto-close with a link to the original, and
   "Set detection status" (`beb56cc40d334583671ca91e6e390056`) sets `status: closed`.
8. **Validate, then deploy.** Run `validate.py`, then import and release to the CID.

## Key Actions

Every id and `version_constraint` below is copied directly from the source YAML.

| Action | `id` | version_constraint |
|--------|------|--------------------|
| Event Query (`Inline.QueryEvent`) | `cdf5c3e0d69f156eaaf56c1f5d3f1b66` | `~1` |
| Create variable | `702d15788dbbffdf0b68d8e2f3599aa4` | `~1` (class `CreateVariable`) |
| Update variable | `6c6eab39063fa3b72d98c82af60deb8a` | `~1` (class `UpdateVariable`) |
| Add tag to alert | `6de8a462880ad419680ed5c291b9413f` | `~0` (example omits it; correct explicit value is `~0` per the action catalog, no semantic_version) |
| Add comment to detection | `7b77cb5d5ff2651cc51c7c4c610d54d1` | `~0` |
| Set detection status | `beb56cc40d334583671ca91e6e390056` | `~0` |

The two `Inline.QueryEvent` actions carry `class: Inline.QueryEvent` and `~1`, which matches the
authoring skill's rule that this native action uses `~1`. "Set detection status" is `~0` in the
source, a useful reminder that a sophisticated-looking action can still be `~0`: the constraint is
`~<major>` of the action's `semantic_version` (here it has none, so `~0`), not a guess from the
action's name.

## When to Route Elsewhere

The dedup logic lives entirely in the Event Query's CQL and the workflow's loop, so this stays in
Falcon Fusion. Move to a Foundry function only if you need to persist a cross-workflow dedup ledger, run
transformations too complex for CQL, or pair the dedup with a UI or collection.