Intune change alerts

Start with a destination and an alert

Open Alerts in the sidebar for the selected tenant. Its tabs separate Alerts, Channels, Change watching and Deliveries. A channel is a destination; an alert selects the events that go to it. Adding a channel alone does not start sending every Intune change.

When the tenant cannot send yet, Set up alerts walks through the destination, recommended events, optional Azure running and review. Turn on alerts creates the chosen configuration and sends a test. The recommended set emphasizes backup and restore problems, deleted or unassigned policies and Conditional Access changes rather than successful backups.

The guided setup enables the change watching it needs, with a default interval of 15 minutes, TenuVault's own changes ignored and actor details off. These remain ordinary channels and alerts you can edit later. If the test fails, the saved configuration is not undone; check delivery and permissions before relying on it.

Choose a channel that fits the response

Teams uses a Workflows incoming webhook. Create the workflow in the destination channel, copy its URL and add it as a Teams channel in TenuVault. Review workflow ownership: a destination tied to a disabled account can stop working even though the alert in TenuVault still exists.

Email needs its own sending setup and permissions, while a webhook sends a signed JSON event to a public HTTPS endpoint. This computer uses a local system notification and only appears while TenuVault runs. Send a test to the actual intended destination instead of judging delivery by whether the channel saved.

Notify when an Intune policy changes

On Change watching, enable Intune and choose the audit categories you need. Selecting no categories watches every reported category. Those choices control what is read at all, so an alert cannot recover a category the watcher excluded. Poll now uses the saved settings when desktop watching owns the work.

In an alert containing Intune change events, use Which changes to narrow the result. Choose created, updated, deleted, assigned or unassigned operations, then a policy name if needed. Contains matches a substring; Exact name matches the full name. A rename stops an exact-name alert from matching until you update it.

Changed settings contain is narrower still: it matches setting names reported for updates. Creates, deletions and assignment operations do not name changed settings and will not pass that filter. Leave that field empty when the alert must catch deletion or unassignment, even if you care about a particular setting too.

Understand the detail an alert can carry

Alerts name changed settings where audit evidence supports the comparison. TenuVault compares old and new property values in memory and retains the setting names, not those values. Settings Catalog audit updates do not provide old values, so those events can arrive without a list of changed setting names.

Choose One summary per check or One alert per change. Individual change messages are capped at 20 per check, with additional matches grouped into a summary. Repeated edits can be collapsed, so a summary line is not necessarily a separate human action for each listed setting.

Actor details are off by default. Enable them only for destinations permitted to receive that personal data, and interpret the recorded identity alongside the audit event. Notifications carry event details and setting names, not a recoverable policy payload; keep backups for the actual configuration history.

• Investigate who changed a policy

Keep watching while the computer is off

Desktop watching needs TenuVault running and a tenant sign-in. It catches up after being closed, but a long gap can leave older changes missing. Turning watching off and back on starts from that moment, so it is not a way to replay every change made while the feature was disabled.

For continuous operation without an admin computer, configure the Azure watcher and copy the reviewed alerts to it. Enable An Azure watcher owns change alerts for this tenant so desktop polling stands down instead of duplicating the cloud watcher's work. Conditional Access watching needs its additional setup before handing that service over.

TenuVault reads the Azure watcher heartbeat and can send Watcher stale when it is missing or older than three hours. A watcher with failed runs can still write a heartbeat, so keep the Azure Monitor failure alert from its setup as well. A recent heartbeat alone does not prove every channel delivered successfully.

Verify delivery and maintain the destination

Open Deliveries to inspect sent, waiting and failed attempts. View shows the stored event as the email, Teams card or webhook payload, and Retry sends a failed delivery again. Delivery is at least once: a receiver may accept a message while its acknowledgement is lost, so the same event can arrive again with the same eventId.

After editing a channel, verify queued delivery and the next real change. A recreated Teams workflow or changed email sender can require new destination setup even though the alert filters remain correct. Removing a channel leaves alerts without destinations turned off rather than silently inventing a replacement.

• Test each destination and inspect the recorded delivery result.
• Check that watcher categories and alert filters include the change you need.
• Keep deletion alerts free of a setting-name filter that would exclude them.
• Review watcher health, sending permissions and destination ownership after changes.