Rules engine

• Trigger — what event starts the rule. RMM alert created, ticket opened, backup job failed, contract expiring, etc. Triggers are scoped to a single integration category.
• Conditions — optional filters. “Only if severity is critical”, “only for customers with a managed-services contract”, “only between business hours”. Conditions can read fields from the triggering record + any related customer record.
• Actions — what the rule does. Create a ticket, send an email, acknowledge an alert, post to Slack, update a CRM field. Actions write back to the relevant integration so the side effect lands in the source system.

Visit Rules and click Browse templates. The library carries opinionated automations that map to the highest-value MSP motions:

• RMM critical alert with no open ticket → create ticket
• Backup failure 3 runs in a row → notify customer + open ticket
• Contract expiring in 30 days → assign to account owner
• Past-standard-age device → flag in next QBR
• Below-margin license SKU detected → escalate to ops lead
• Ticket in “Awaiting Customer” for 7+ days → auto-close with reminder

Each template lands as a draft rule with the wiring filled in; you adjust the conditions to your environment, dry-run, then enable.

Every new rule starts in dry-run. The rule evaluates against the same triggers as a live rule, logs every would-fire decision in the rule’s history, but does not dispatch any actions. Dry-run mode is how you verify a rule will fire on the records you expect — and only those — before it touches your PSA / RMM / customer.

1. Save the rule. It defaults to dry-run.
2. Wait an hour (or trigger manually if the integration supports it). Open the rule’s History tab.
3. Walk through the would-fire entries. Verify each would have done the right thing on the right record.
4. If anything is off, adjust the conditions and stay in dry-run.
5. When dry-run looks clean, flip the rule to Live.

Actions are integration-scoped. Each connected integration contributes its own action types; the rules-engine action-builder filters available actions to integrations you’ve connected.

• PSA — create_ticket, update_ticket_status, add_ticket_note, close_ticket. Available for every PSA in its connected category (ConnectWise, Autotask, HaloPSA, Atera).
• RMM — acknowledge_alert, resolve_alert (where vendor APIs support it). NinjaOne supports the full set; Atera’s public API is read-only on alerts and those actions are intentionally not offered.
• Backup — read-only today. Action types are limited to fanning failures into your PSA / notifications.
• Notifications — send_email, post_slack_message, fire_webhook. Always available.

• Per-integration rate limits — every action is rate-limited per integration so a runaway rule can’t flood your PSA. Defaults are conservative; tune in Admin → Rules.
• Dead-letter queue — failed actions land in the DLQ for manual inspection, not silent loss.
• Audit log on every dispatch — every action captures the full request payload. See Audit log.
• Concurrency cap per rule — a rule that matches 200 records at once doesn’t fire 200 actions simultaneously; dispatch is serialized per rule with a small concurrency budget.