How to combine delaying of notifications with both dedup & time conditions?

Question

I'm looking to create a notification policy where I can apply both

- delaying until 9:00 AM next Weekday
OR 
- delaying until the count exceeds 5 within 30 minutes

whatever occurs first

I'm able to only select one (images attached below)

If I duplicate this it won't work as JSM will stop evaluation when one of the conditions is met so the second one in line will never fire

Nivruth Nandigam · Answer

Thanks @Ibrahim Khalil for the suggestion! However, this approach may not work for my use case because the alerts are coming in as JSM Alerts (from Splunk via the alerting integration), not as Jira issues. These are two different objects in JSM I think.

Specifically:

* Automation for Jira operates on Jira issues, not JSM alerts — so there's no trigger available for alert deduplication count exceeding a threshold.
* The "Notified" label workaround assumes issue-level fields, which don't exist on alert objects, does it?
* Scheduled JQL queries in Automation run against issues, not the alerts inbox — so the 9 AM batch rule wouldn't have visibility into alert state at all.

To restate the core problem: I have JSM Alerts (not issues) flowing in from Splunk, all at default P3 priority. Within a single Notification Policy, I want the delay to fire on whichever comes first:

* Deduplication count exceeds 5 within 30 minutes → notify immediately, OR
* Neither condition met → hold until 9:00 AM next weekday

The limitation is that JSM's "Delay or turn off" action only accepts a single condition (either time-based OR dedup-based, not both), and the first-match policy chain means two separate policies can't collaborate on the same alert.

Is there a native way to achieve this within JSM Alerts + Notification Policies specifically?

Ibrahim Khalil_ev9ya4 · Answer

Since JSM notification policies follow a "First Match" rule, they cannot natively evaluate two independent conditions for the same event. To solve this, move the logic to Automation for Jira by creating two separate rules—one for the count threshold and a scheduled one for the 9:00 AM weekday batch. Use a shared "Notified" label on the issues so that whichever rule triggers first clears the queue and prevents the second one from double-firing.