Skip to main content
1. New

Configurable Cooldown Window for Webhook-Triggered Plugins/Notifications (Ambient Agents)

Related products:Agent Studio
  • July 16, 2026
  • 0 replies
  • 33 views

  • Participating Frequently

Summary

We're building ambient agents that send notifications via webhooks from device monitoring tools (Zscaler, Tanium, Aternity). Since these tools re-fire alerts continuously while an issue persists, users get flooded with duplicate notifications for the same issue.

We need a configurable Cooldown Feature — either new or an extension of the existing 1-hour de-duplication logic — that suppresses repeat notifications per user/issue over longer windows (7–15+ days), without requiring an external database.

The Problem

  • Webhook storms: Monitoring tools fire repeatedly as long as a condition holds — they have no awareness of whether a user was already notified.
  • De-dup window too short: Moveworks' current de-duplication caps out at 1 hour, but many device issues take days to resolve, causing repeated alerts.
  • Costly workaround: Without native support, we have to build/maintain an external database just to track notification state and gate webhooks before they reach Moveworks — adding latency, complexity, and ongoing maintenance.

Proposed Solution

Let devs/admins set a custom cooldown duration on webhook-triggered plugins natively in Moveworks. On each incoming webhook, a Cooldown Engine checks whether the target user already got a notification for that issue within the window:

  • If yes → suppress the notification.
  • If no → send it and reset the cooldown timer.

Key Requirements

  1. Custom cooldown windows — admin-configurable per plugin (hours or days, supporting 15+ days).
  2. Flexible uniqueness keys — cooldown logic based on combinations like User ID + Issue/Alert ID, or Plugin ID.

Business Value

  • Better UX: Cuts notification fatigue, reduces risk of users muting/ignoring the bot.
  • Faster time-to-value: Enables proactive IT use cases out-of-the-box, no external middleware needed.
  • Lower overhead: Keeps the entire logic loop native to Moveworks, reducing architecture and API costs.

 

Note: This request seems related to the below 2 requests about notifications management. But I created a separate request because the other 2 are talking about USER preferences, while we are looking for developers to be able to set this cool down duration:

End User Notification controls in Copilot | Community

User Preference & Notification Management Framework | Community