Skip to main content
Notification rules let you decide who gets emailed when something happens in the PSA — without writing automation rules. The engine is purpose-built for ticket events, runs server-side, and routes to a list of recipient emails per rule.
This page covers the Notification Rules screen — org-wide rules that route ticket events to a recipient list. It’s linked from the main Settings → Notification Preferences page, which is a separate, per-user screen controlling which platform notifications you personally receive (email, in-app, sound, desktop) and alerts when your organization’s mailbox connection breaks. The two work independently: your personal preferences don’t affect whether a rule fires, and a rule firing doesn’t depend on the recipient’s own notification preferences.

​
What it does

  • Personal and team rules — any user can create a rule for themselves; admins can additionally create “team” rules that route to other org users and free-text email addresses (a tech’s own rule can only ever email the tech themself)
  • Ticket-spike detection — a built-in detector that fires when a portal company hits 5+ new tickets, or 3+ new tickets in the same category, within a 10-minute window
  • Filterable triggers — match on ticket priority (one value), category (exact text match), a specific client, and/or “only when assigned to me”
  • Recipient cap — up to 25 org-user recipients and 25 free-text email addresses per rule (defense against accidentally CC-ing the entire org)
  • Quiet hours and cooldown — suppress a rule during a configured time window (with a priority bypass list), and throttle repeat emails to the same recipient
  • Org-scoped — rules are tenant-scoped at the API layer; an MSP cannot receive a notification for another MSP’s tickets

​
How to create a rule

1

Open the rules page

Navigate to Settings → Notification Preferences, then click the Notification Rules card near the top of the page.
2

Click New Rule

Enter a descriptive name (e.g., “Critical tickets for Acme Health → on-call inbox”).
3

Choose the trigger event(s)

Check as many as you want:
  • New ticket — fires on new ticket from any source
  • Status changed — fires on every status transition
  • Reply added — fires on every customer-visible reply
  • Ticket spike — the built-in spike detector (see below)
  • SLA warning — fires when a ticket’s SLA timer enters the at-risk window before breach
  • Escalated — fires when an automation rule or operator moves a ticket to ESCALATED status
4

Add filters (optional but recommended)

  • Client — narrow to one portal company, or leave as “Any client”
  • Priority — one of LOW / MEDIUM / HIGH / CRITICAL, or “Any priority”
  • Category — match an exact category string
  • Only fire when the ticket is assigned to me — a checkbox, not a technician picker
  • Only fire when the ticket is part of a spike — a checkbox, independent of the “Ticket spike” trigger above
All filters AND together: the rule fires only when every filter you set matches.
5

Add recipients (optional)

Leave this blank to email only yourself. Admins can additionally add other org users and comma-separated extra email addresses (e.g., oncall@msp.com) — non-admins can only route a rule to themselves.
6

Set quiet hours and cooldown (optional)

Quiet hours suppress the rule during a from/to time window in your organization’s timezone, unless the ticket’s priority is on the bypass list you check. Cooldown sets a minimum number of seconds between two emails to the same recipient from this rule (default 60).
7

Save

New rules are active immediately — there’s no separate “Enabled” toggle to flip on creation; use the Power icon on an existing rule to pause or resume it later.

​
Customer priority is the filter source of truth

The Priority filter matches against the value set at ticket creation by the customer (portal, Teams bot), the inbound-email classifier, or the operator. The AI auto-analyzer never changes priority on its own (see Automations & AI → AI and ticket priority), so a rule keyed on CRITICAL will fire correctly for every customer-submitted CRITICAL ticket.

​
Ticket-spike detection

A spike fires when a portal company crosses either of two independent thresholds within a rolling 10-minute window: 5 or more new tickets total, or 3 or more new tickets sharing the same category. Either one fires the Ticket spike trigger. Useful for catching site-wide outages early — one rule with this trigger and your on-call inbox covers every customer. The spike detector runs as part of the same background pipeline that processes new tickets, so the alert email lands within seconds of the ticket that crosses the threshold.

​
Frequently asked questions

No. Notification rules only send emails. For state-changing automations (assign / change priority / set status), use PSA → Automations — that engine is separate.
The rule defaults to emailing just you, the rule’s owner — this is the normal case for a personal rule. You only need the recipients field for a team rule that should also reach other people.
Click the power icon on the rule in the rules list to disable it. The rule is preserved but won’t fire until you re-enable it the same way.
Only within one rule — if a rule lists the same address in both its user recipients and its extra emails, that person gets one email, not two. Across two DIFFERENT rules, dedup does not apply: if two separate rules both match the same ticket event and both list alice@example.com, alice gets two separate emails, one per rule, each naming that rule.
Yes — set the Client filter to one specific client, or create one rule per client. Notification rules are tenant-scoped at the API layer; you cannot accidentally route another MSP’s tickets to your inbox.