2026-08-12 - Workflow Wednesday - Taming Noisy Alerts with Deduplication
Welcome back to Workflow Wednesday!
If you’ve ever had a single noisy alert turn into endless workflow executions, email notifications, and duplicate cases, this one’s for you.
The new Deduplicate action gives Fusion workflows a simple way to recognize when they’ve already handled the same activity and decide what should happen next - instead of repeating the same work over and over again.
We're just scratching the surface of what you can do with this. You can throttle noisy detection sources, suppress repeat notifications, avoid rerunning expensive enrichment, prevent duplicate remediation actions, or make sure only one workflow execution performs a shared task while the others reuse its result.
At its core, Deduplicate answers one question: Have I already handled this combination of values within this period?
You define that combination by building a key from one or more fields, choose whether the key is scoped to a single workflow or shared across the CID, and set how long the entry should remain active. From there, Fusion handles the coordination.
The Example
Imagine the same phishing campaign targets 25 users. Each email generates a separate detection, but they all share the same detection name, sender, and subject.
Without deduplication, our workflow could create 25 separate cases for what is really one phishing campaign. With deduplication, we can turn that into: 25 phishing detections → 1 case containing all 25 detections
Here’s how.
Step 1: Define the Trigger
We’ll start by creating a workflow with the following trigger:
Detection → NG-SIEM Third Party Detection
Since we don’t want every third-party detection entering this workflow, we’ll add a condition immediately after the trigger to narrow things down to the phishing detections we care about.
For this example, we’ll use:
- Vendor includes (exact match): Mimecast
- Name is equal to: Phishing Detection
This gives us a clean starting point: only the Mimecast phishing detections we want to correlate will continue through the workflow.
From here, we can start deciding whether each detection represents a new phishing campaign or one we’re already tracking.
Step 2: Create the Deduplication Key
Next, we need to decide what makes two detections part of the same activity.
For this example, we’ll combine three fields: Detection Name + Sender + Subject
One important detail: Deduplicate keys can only contain letters, numbers, underscores, and hyphens. That means we can’t pass values like email addresses or subjects directly into the Key field. Instead, use the cs.hash.sha1 Data Transformation function to hash the fields into a valid deduplication key.
In the Key field, we’ll use:
${cs.hash.sha1(data['GetDetectionDetails.name'] + "|" + data['GetDetectionDetails.raw_response'].header_from + "|" + data['GetDetectionDetails.raw_response'].subject)}
Depending on the fields you want to include, you may need to add a Get detection details action first. That’s what I’m doing here so we can pull the sender and subject into the workflow.
Now, any detection with the same detection name, sender, and subject will generate the same hash and resolve to the same deduplication entry for the period we configure.
Step 3: Configure the Scope and Period
Next, we configure how broadly the deduplication entry should apply.
The Deduplicate action supports two scopes:
- Workflow: The key is shared only between executions of this workflow.
- CID: The key can be shared across workflows in the CID.
For this example, we’ll use workflow scope, since we only want executions of this phishing workflow to share the entry.
We also need to specify the period in seconds. We’ll use 86400, which gives us a 24-hour deduplication window.
Step 4: Branch on Whether It’s a Duplicate
After Deduplicate runs, it tells us whether the key already exists.
We’ll add a condition: If Duplicate is equal to False
That gives us two paths:
- TRUE: Fusion has not seen this key during the configured period.
- ELSE: The key already exists, so this execution is a duplicate.
Only the first matching detection follows the TRUE path and performs the primary work.
Step 5: Create the Case
If Duplicate = False, we know this is the first detection associated with this key. Even if several detections with the same key arrive at the exact same time, only one execution can claim the deduplication entry and follow this path.
On the TRUE path, we’ll:
- Create a new phishing case.
- Include the original Detection ID in the case.
- Store the newly created Case ID using Set Deduplicate Entry Metadata.
For the case name, we can use the sender and subject to make it immediately recognizable:
Phishing Campaign - ${data['GetDetectionDetails.raw_response'].header_from} - ${data['GetDetectionDetails.raw_response'].subject}
Next, add Set Deduplicate Entry Metadata.
Use the same key we created earlier, then set the Metadata field to the Case ID returned by Create a new Case: ${data['CreateANewCase.id']}
This is the important part: we’re attaching the Case ID to the deduplication entry so every duplicate execution knows which case it belongs to.
Step 6: Handle the Duplicates
Now for the ELSE path.
If an execution lands here, Fusion already has an active deduplication entry for that combination of detection name, sender, and subject.
First, add Wait for Deduplicate Entry Metadata and use the same key again.
Why add the wait action? A duplicate detection could arrive milliseconds after the first one - before the original workflow execution has finished creating the case and storing its case ID.
Wait for Deduplicate Entry Metadata handles that timing problem for us. It waits for the original execution to populate the metadata and returns as soon as that value is available.
Once we have the Case ID, we'll use the Add detections to case action.
Set the Case ID to the metadata returned by the previous action: ${data['WaitForDeduplicateEntryMetadata.metadata']}
Then add the current Detection ID to that case.
Note: For the Case ID field, you’ll need to switch to the Text input option and paste the expression above.
Let's now test our workflow. Here's the first execution for a given key:
Subsequent execution(s) using the same key:
Instead of creating a new case every time the same phishing campaign generates another detection, each matching detection now gets added back to the case created by the first execution.
The New Actions
The release includes six new actions:
- Deduplicate
- Set Deduplicate Entry Metadata
- Wait for Deduplicate Entry Metadata
- View Deduplicate Entry
- Delete Deduplicate Entry
- View All Deduplicate Entries
These actions give Fusion workflows a native way to suppress duplicate processing, reduce case sprawl, throttle noisy activity, reuse work across executions, and coordinate workflows around shared state.
And a fun detail before I wrap this up:
After writing this post, I asked Claude Code to build the same workflow using the newly released Fusion Skills. It did pretty well!
That deserves its own post, so we’ll dig into how it works in an upcoming Workflow Wednesday.
That’s it for this week!
