Navigation
10.21. How RMM Integrations Work in AlgaPSA: Devices, Alerts, and Tickets in One Place
Connect your RMM to AlgaPSA so monitored devices become assets, device alerts become routed tickets, and resolved alerts close their own tickets. Covers the shared model behind NinjaOne, Tactical RMM, Tanium, Level, and Huntress.
Your technicians work tickets in AlgaPSA, but the first sign of a client problem usually appears in your RMM. An RMM integration closes that gap. Once you connect a provider, AlgaPSA maps RMM organizations to your clients, syncs monitored devices into Assets, and turns device alerts into tickets that land on the right board with the right priority. When the alert clears in the RMM, AlgaPSA can close the ticket for you. Your team gets one queue to watch instead of two.
This guide explains the model RMM integrations share. Each provider with a setup guide is linked here: NinjaOne, Tactical RMM, Level, and Huntress. Alert rules, maintenance windows, and polling are covered in Turn RMM Alerts into Tickets.
Figure 1: The RMM tab under Admin Settings > Integrations lists available providers with connection status. Select a provider to open its configuration panel.
What an RMM integration gives your MSP
| Capability | What it means for your MSP |
|---|---|
| Organization mapping | RMM organizations or groups are matched to AlgaPSA clients, so every synced device and alert is attributed to the right client from day one. Each mapping also supports a Default Notification Contact: the contact whose name appears on alert-created tickets and who receives the Ticket Created client email when an alert opens a ticket. |
| Device sync | Monitored endpoints become AlgaPSA assets. Dispatchers see the device on the client record, and tickets can reference the exact machine. |
| Alert ingestion | Device alerts flow into AlgaPSA in real time through webhooks, on a schedule through polling, or both, depending on the provider. |
| Alert automation | Alert rules decide which alerts become tickets, which board and priority they get, and who is notified. Maintenance windows suppress expected noise. |
| Duplicate protection | Repeat alerts for the same condition on the same device attach to the existing open ticket instead of creating new ones. A flapping disk check produces one ticket, not forty. |
| Lifecycle sync | When the RMM resolves an alert, AlgaPSA can close the ticket, as long as nobody has started working it. When a technician closes the ticket, AlgaPSA can reset the alert in the RMM. |
The shared model
Most providers follow the same flow. The provider guides cover the details of each step.
- Connect. Navigate to Settings > General in the sidebar to open Admin Settings, then select Integrations (under Data & Integration) and open the RMM tab. Enter the provider's credentials and test the connection. NinjaOne uses OAuth; Tactical RMM, Tanium, Level, and Huntress use API keys.
- Map organizations to clients. Sync the provider's organization or group list, then assign each one to an AlgaPSA client. Unmapped organizations are skipped (Huntress is the exception: its incidents fall back to a triage client so nothing is dropped).
- Sync devices. Devices from mapped organizations become AlgaPSA assets and stay linked to their RMM identity.
- Receive alerts. Webhook-capable providers push alerts the moment they fire. Polling-capable providers are checked on a schedule you control. Both paths feed the same pipeline.
- Automate tickets. Alert rules evaluate each incoming alert and create a routed ticket, with templates, priority mapping, assignment, and notifications. See Turn RMM Alerts into Tickets.
- Stay in sync. Resolved alerts close their untouched tickets. Closed tickets can reset their alerts in the RMM. Polling heals anything a missed webhook left behind.
Which provider does what
| NinjaOne | Tactical RMM | Tanium | Level | Huntress | |
|---|---|---|---|---|---|
| Edition | Enterprise | Community and Enterprise | Enterprise | Enterprise | Enterprise |
| Authentication | OAuth (client ID and secret) | API key or Knox username/password | Gateway URL and API token | API key | API key and secret |
| Device sync | Yes | Yes | Yes (by computer group) | Yes (by group) | No |
| Real-time alerts (webhooks) | Yes | Yes (alert action webhook) | No | Yes (automation webhook) | No |
| Alert polling | Yes | Yes | No | No | Yes (incident polling) |
| Alert rules and maintenance windows | Yes | Yes | No | Yes | No (uses its own ticket routing) |
| Patch and software inventory | Yes | Software inventory | Inventory sync | No | No |
| Remote access | Not currently available in-product | Not currently available in-product | Not currently available in-product | Not currently available in-product | Not currently available in-product |
Huntress is a managed security service rather than a traditional RMM. Instead of raw device alerts, its SOC-reviewed incident reports become tickets through a dedicated routing configuration. See Huntress Integration.
Where things land in AlgaPSA
- Assets. Synced devices appear under the mapped client's assets, carrying hostname, status, and the RMM identity used to match future alerts.
- Tickets. Alert-created tickets open on the board your rule chooses, in the board's default status, with a system note recording the alert that created them. Repeat firings add occurrence notes to the same ticket. If the organization mapping has a Default Notification Contact set, that contact is attached to the ticket and receives the Ticket Created client email; otherwise AlgaPSA falls back to the client's primary contact, and if neither is available the ticket is created without a contact.
- Notifications. Rules can notify chosen team members in-app and by email when an alert creates a ticket. Manage the RMM alert category by navigating to Settings > General in the sidebar to open Admin Settings, then selecting Notifications (under Communication).
Operational checks
- After connecting a provider, confirm the integration shows Connected on the RMM tab.
- After mapping organizations, sync devices and spot-check one client's asset list.
- Fire or pick a test alert in the RMM and confirm a ticket appears on the expected board within a minute (webhooks) or one polling interval.
- Review alert rules before going live so the catch-all behavior matches your dispatch process.
Related topics
- Turn RMM Alerts into Tickets: Alert Rules, Maintenance Windows, and Polling — the automation layer shared by all providers
- NinjaOne RMM Integration — OAuth setup, organization mapping, fleet compliance
- Tactical RMM Integration — self-hosted Tactical with webhook alerts
- Level RMM Integration — group-based sync and automation webhooks
- Huntress Integration — SOC incident reports as tickets