# RMM Platforms

> Alerts from your RMM raise incidents against the right client, site and device - and close again when the alert clears.

**URL:** https://cubemsp.co.uk/integrations/rmm-platforms

Keep the RMM you chose. It answers a different question from this one.

We have no interest in replacing your remote monitoring and management platform. A good RMM is the product of years of agent engineering and we would be foolish to compete with it. What matters is that the alert it raises becomes an incident attached to the right client, the right site and the right service, so that the business consequences of a technical event are visible in the same place as everything else. CubeMSP integrates with RMM platforms through webhooks and the API, in whichever direction each one supports.

## Details

- **Category:** Monitoring & management
- **Licence cost:** included, no per-connector charge
- **Platform:** CubeMSP (https://cubemsp.co.uk/platform)

## What syncs

- **Alerts as incidents** (Into CubeMSP): A monitoring alert creates an incident with the client, site and device resolved automatically, at a priority you map from the alert severity.
- **Alert clearance** (Into CubeMSP): When the underlying alert clears, the incident is updated or resolved according to your rules, so self-healing events do not leave a queue of phantom work.
- **Device and asset inventory** (Into CubeMSP): Managed device counts per client, available for reconciliation against the services you are billing for.
- **Client and site mapping** (Out of CubeMSP): The client and site structure held in CubeMSP exposed through the API, so the two systems agree on who is who rather than maintaining separate lists.

## How it behaves

- **Noise filtered before it becomes a queue:** Mapping rules decide which alert types raise an incident, at what priority, and which ones simply log. An RMM that raises a ticket for everything produces a queue nobody reads.
- **Related alerts grouped:** Forty devices at one site going offline together is one incident with forty affected devices, not forty incidents to be closed individually.
- **Device counts reconciled:** Managed endpoints reported by the RMM against endpoints billed as a service. The drift is usually real and usually in the client’s favour.
- **Alerts attached to the service:** An alert on a monitored server attaches to the service that covers it, so recurring faults are visible against what you are contracted to support.

## Setup

1. Point your RMM’s webhook or notification channel at the CubeMSP endpoint and supply an API key.
2. Map client identifiers between the two systems - usually a one-off exercise done during migration.
3. Define which alert types raise incidents and at what priority, then tune it over the first fortnight rather than trying to get it right in advance.

## Frequently asked questions

**Which RMM platforms are supported?**

Any platform that can send a webhook or be polled through a documented API - which is all the mainstream ones. We build and test the specific mapping for your platform during implementation rather than shipping a directory of connectors we cannot all maintain properly.

**Will it flood our queue with alerts?**

Not if the mapping is set up properly, and getting that right is part of implementation. Only the alert types you nominate raise incidents; the rest can log against the client without creating work.

**Do incidents close automatically when an alert clears?**

They can, per alert type. Some alerts are resolved by clearing; others need a human to confirm. You decide which are which.

**Can we keep using our RMM’s own ticketing?**

You can, but running two queues means neither one is complete, and the reporting from both becomes unreliable. Our advice is to pick one, and if it is the RMM’s then you probably do not need us yet.

## Related integrations

- **Microsoft 365** - Single sign-on through Entra ID, licence counts reconciled per client, and incidents raised from mail without leaving the tenant you already manage. https://cubemsp.co.uk/integrations/microsoft-365
- **REST API & Webhooks** - A documented REST API and webhooks on every meaningful event - included in the platform, not licensed per connection. https://cubemsp.co.uk/integrations/rest-api
- **Microsoft Teams** - Assignment, escalation and breach notifications in the channel your engineers already have open, without another application to watch. https://cubemsp.co.uk/integrations/microsoft-teams

## Contact

- **Product:** CubeMSP
- **Trading name of:** Cube Systems Limited (company number 17220899, ICO registration number ZC216972)
- **Email:** hello@cubemsp.co.uk
- **Sales:** sales@cubemsp.co.uk
- **Support:** support@cubemsp.co.uk
- **Telephone:** 01234 672 617 (+441234672617)
- **Address:** Unit 11, Olney Business Park, Osier Way, Olney, Buckinghamshire, MK46 5FP
- **Opening hours:** Monday to Friday, 9am to 5.30pm
- **Part of:** Crushed Ice Group (https://crushedicegroup.co.uk)