Set who gets told about a device alert, and tune the platform's own alert conditions
Device alert response, plus the Billing, Expirations, Operations and Security alert-condition groups, all live on Settings > System > Alerts & Notifications.
What you will have
- See the two decisions a device alert makes at each severity band: who hears about it, and whether it opens a ticket.
- Read the shipped defaults and know why Info stays quiet.
- Give one client its own answers with a client exception, without changing the defaults for anyone else.
- Find these settings again on the Automations ledger, as the read-only system rules they materialize into.
- Turn the platform's other alert conditions on or off, and set a day threshold where one applies.
- Know what the Integration Credential Invalid alert checks and why it can raise more than one row for Microsoft.
- Know what happens to a ticket once the alert behind it clears, and whether muting an alert still works.
Why it works this way
This card decides audience and ticket only. There is deliberately no channel choice here - each person who is told then hears about it by whatever channel they picked on their own notification settings, including a daily digest instead of one message per alert. A channel column on this card would put the same decision in two places.
Info is quiet on purpose: alerts are always recorded on the device and on the Alerts Desk either way, so the shipped defaults only add a person once the signal is worth interrupting someone for.
Security, Billing, Operations and Expirations each toggle and, where it applies, a day threshold - there is no per-alert recipient picker. When an enabled condition trips, the daily alert check notifies every Admin and Super Admin account on the instance, not a chosen list.
Mute lives on the alert row itself, on the device's Alerts tab, because it is a judgement about one machine rather than a policy for the fleet - it is not pictured on this settings page, but muting an alert is checked at the exact moment someone would otherwise have been notified or a ticket opened, and it carries forward if the same condition clears and comes back.
Steps
Open Settings > System > Alerts & Notifications.
This one page holds five independent cards: Device alert response at the top, then Billing, Expirations, Operations and Security alert conditions below it, each with its own Save Changes.
Open Settings > System > Alerts & Notifications. Read the Device alert response card's three severity rows.
Each row is two decisions and no more: who hears about it, and does it open a ticket. The shipped defaults are Info - No one (desk only), no ticket; Warning - Assigned tech, falling back to the client's pod when that client has no dedicated tech, no ticket; Critical - All techs, and Open a ticket is on. "Assigned tech", "Client's pod", "All techs", "Co-managed IT contacts" and "Client primary contact" are the audiences this card offers; a client contact who is told about an alert gets a link to the device on their own portal, never to an admin page they cannot open.
Read the Device alert response card's three severity rows. Add a client exception and give it its own answers.
Add an exception for a client starts the new row as a copy of the defaults, so only the row that actually differs needs changing. This walkthrough adds an exception for Bluebird Dental and sets its Critical audience to No one (desk only), leaving its Open a ticket toggle on - everyone not listed here keeps following the defaults, and always will.
Add a client exception and give it its own answers. Find the same setting again on the Automations ledger.
Automations > Library, filtered to Devices, lists Device alert response - Critical, Device alert response - ticket close, and Device alert response - Warning as locked system rules, each triggered by Device Alert Raised or Device Alert Resolved. There is no Info rule at all: a band set to No one and no ticket does nothing, so nothing is materialized for it. These rows are read-only here and link back to the Alerts & Notifications page, because that page is where the setting actually lives.
Find the same setting again on the Automations ledger. Scroll to the four alert-condition groups below Device alert response.
Billing, Expirations, Operations and Security are independent groups, each edited in its own card with its own Save Changes button (Expirations is collapsed here to fit the frame; it holds all 8 of its own conditions expanded). Each condition is an on/off toggle plus, where it applies, a day threshold - there is no per-alert recipient picker on any of them.
Scroll to the four alert-condition groups below Device alert response. Read the Operations group's Integration Credential Invalid condition.
This one checks whether a saved integration login still works, and can fire for three separate reasons: a stored secret the portal can no longer read, a vendor that rejected the saved key with a 401 or 403, or a Microsoft app that needs new permissions or logged an error. It names which reason it is and the matching fix - enter a new secret, reconnect, or approve new permissions - and stays quiet for an integration nobody ever configured or one turned off on purpose. Microsoft can raise more than one row at once, since it runs on three separate apps.
Read the Operations group's Integration Credential Invalid condition. Know what happens to the ticket once the alert behind it clears.
It depends on why it cleared. If the platform's own automatic remediation ran and the condition then cleared, the ticket closes with a note naming the repair that ran. If the condition simply went away on its own, the ticket stays open for a human, with a note saying it cleared by itself. Either way the alert itself stays visible as auto-resolved, with its reason, and one alert opens at most one ticket no matter how many times it re-trips.
Know that mute still works, even though it is not on this page.
Mute lives on the alert row itself, on the device's Alerts tab, because it is a judgement about one machine rather than a policy for the whole fleet. Muting silences that condition on that device, and the mute carries forward if the same condition clears and later comes back. There is no snooze - acknowledging an alert on the Alerts Desk is how a row leaves the working view, not a timer.
If it did not work
- If a card's Save Changes button stays disabled, nothing on that card has changed yet - it only lights up once a value differs from what is saved.
- If Add an exception for a client is empty, every client already has its own exception row; remove one first to add a different client.
- If a locked automation on the Devices filter is missing a band, that band is set to No one and no ticket - nothing is materialized for a band that does nothing.
Questions this page answers
What does Device alert response decide?
Two things, per severity band: who gets told when a device alert is raised, and whether that alert opens a ticket. Nothing else. What COUNTS as an alert is a monitoring threshold on the RMM policy, not here, and how each person hears about it is their own notification setting. Detection there, response here, delivery in each person's preferences.
Why is there no email or in-app choice on this card?
Because that choice already has a home, and it belongs to the person receiving the alert rather than to the person configuring it. This card names the audience; each of those people then gets it by whatever channel they have chosen on their own notification preferences, including a daily digest instead of one message per alert. Putting a channel column here would mean two places decide the same thing, and they would disagree the first time somebody changed one of them.
What are the shipped defaults?
Info tells no one: it is recorded on the device and on the Alerts Desk, and that is where it should be read. Warning tells the client's assigned tech, falling back to the client's pod when that client has no dedicated tech. Critical tells all techs and opens a ticket. Alerts are quiet by default on purpose, so turning an audience ON is a decision somebody makes, not one they inherit.
What does each audience mean?
"Assigned tech" is the client's dedicated tech, and falls back to their pod if they have none. "Client's pod" is every assignable member of that pod. "All techs" is every staff member on this instance, which is the widest audience there is. "Co-managed IT contacts" is the client's own elevated portal users, and only reaches co-managed clients. "Client primary contact" is the address on the client record. A client contact who is told about an alert gets a link to the device on their own portal, never to an admin page they cannot open.
When should I add a client exception?
When one client genuinely needs a different answer, for instance a co-managed client whose own IT wants the warnings, or a noisy site where critical should stop opening tickets while it is being rebuilt. An exception starts as a copy of the defaults, so you only change the row that actually differs. Everyone not listed follows the defaults, and always will.
Where do these settings show up as automations?
On the Automations ledger, as locked system rules named "Device alert response". Each active severity band has one, plus one that settles the ticket when an alert clears. They are read-only there and link back to this card, because this card is where the setting lives. A band set to no one and no ticket has no rule at all, since it does nothing.
How do Alert rules work?
Each alert is a rule with an on/off toggle and, where applicable, a threshold (for example days before expiry). There is no per-alert recipient picker, when an enabled condition trips, the daily alert check notifies your Admin and Super Admin accounts. Security, Billing, Operations, and Expirations are independent groups, each edited in its own section with its own Save.
What does this alert check?
The Integration Credential Invalid alert checks whether a saved integration login still works. It can fire for three reasons. A saved secret the portal can no longer read. A vendor that turned down the saved key with a 401 or 403 error. A Microsoft app that needs new permissions, or that logged an error. Each alert says which reason it is, and what to do about it. Fixing each reason means a different step. Type in a new secret. Reconnect. Or approve new permissions. The alert stays quiet if you never set up that integration, or if you turned it off on purpose. Nothing here fixes itself. A turned-down key stops showing once a sync runs after the fix. The other reasons stop once you fix them. Microsoft can raise more than one alert at once, since it uses three separate apps.
What happens to the ticket when the alert clears?
It depends on WHY it cleared, and the alert row records that. If our own automatic remediation ran and the condition then cleared, the ticket closes with a note naming the repair that ran. If the condition simply went away on its own, the ticket stays open with a note saying so, because nobody has confirmed the machine is actually fixed. Either way the alert stays visible as auto-resolved, with its reason. One alert opens at most one ticket, however many times it re-trips.
Does mute still work?
Yes, and it is checked at the moment somebody would have been told. Mute on an alert silences that condition on that device, and carries forward when it resolves and comes back. It lives on the alert row itself, on the device's Alerts tab, because it is a judgement about one machine rather than a policy for the fleet. There is no snooze: acknowledging an alert on the Alerts Desk is how a row leaves the working view.
Was this helpful?