Use NinjaRMM devices and alerts to drive accountable customer support

Updated Wednesday, October 28, 2026 · Marc Staine

The NinjaRMM integration connects monitored organizations and devices with Supportbench Companies, assets and alert cases. It can help a B2B support team understand which customer and device an alert concerns, assign accountable work and retain the investigation alongside the customer’s wider support history. Success depends on more than connecting credentials: the team needs deliberate alert selection, monitored ownership, accurate device relationships and a verified process for returning the provider alert to its intended state.

At a glance

For: support operations leads, integration administrators and agents handling monitored customer devices. Applies to: Supportbench Core.

Start here: Settings → Integrations → NinjaRMM

Confirm credential compatibility before setup · Decide which monitoring events should become support work · Prepare the connection and response process · Configure a compatible connection in Core · Verify organizations, assets and alert cases separately · Work a monitored-device incident with full customer context · Understand alert reset after a case closes · Maintain the connection and handle removal deliberately · Troubleshoot the symptom you can observe

Confirm credential compatibility before setup

Current connection requirement

The current Core connector uses the NinjaRMM v1 access-key and secret-key authentication model. NinjaOne’s current public API guidance describes API 2.0 and OAuth2. Those credentials and flows are not interchangeable. Before a new connection or credential replacement, have Supportbench and the provider confirm that compatible v1 access is available for your installation. Do not enter an OAuth client secret or access token into these fields simply because it is called an API credential.

Provider references checked on 28 October 2026: NinjaOne Public API documentation and NinjaOne OAuth token setup. They explain the provider’s current API options; they are not a verified installation procedure for this Core connector. The old article’s provider menu path for issuing keys is therefore not reproduced as current instructions.

An existing working connection is useful evidence, but it does not establish that the same credential type can still be issued to a new customer. Keep its verified identity and operating history while checking any proposed change.

Decide which monitoring events should become support work

Choice	Operational consequence
Synchronize organizations	Stores an organization preference. The current processor still processes organizations regardless of this checkbox; do not use it as an import boundary.
Synchronize devices	Stores a device preference. The current processor still processes devices regardless of this checkbox. Imported device context can help agents investigate equipment issues, but clearing the control does not stop that import.
Selected alert severities	Only the chosen severities create new alert cases. Selecting no severities means no new alert cases; it is not an “all severities” default.
Division and Queue	Provide the intended routing context. Use a queue that is actively monitored and verify the final case after applicable workflows.
New device and error recipients	Give a named operational team responsibility for new inventory and connection failures. Email alone is not a substitute for checking the actual integration status.

Start with alerts for which your team has an agreed response. If a low-value event generates work that nobody can act on, including it can hide more urgent incidents. Conversely, excluding a severity requires a clear decision about who monitors those events elsewhere.

Prepare the connection and response process

Confirm your role permits administering integrations and editing this settings section. Access to a customer case alone does not grant integration configuration rights.
Confirm the intended provider organization and a compatible credential pair through the compatibility check above. Keep secrets out of documentation, screenshots and support messages.
Choose representative customer organizations and devices for verification. Record how they should appear as Companies and assets in Supportbench. Confirm that processing both types is acceptable; the saved synchronization checkboxes do not currently limit processing.
Agree which alert severities should create cases, the responsible division/queue and the workflow rules that may change ownership or priority.
Choose monitored notification addresses and an owner for repeated synchronization failures. Arrange a controlled provider alert with the monitoring administrator rather than creating a real customer outage.
Record existing settings before changing an established connection. A complete synchronization can affect more records than the one example you intend to inspect.

Configure a compatible connection in Core

Open Settings → Integrations → NinjaRMM. Review the connection status and any Needs attention message.
In Connection, enter the compatible Access key and Secret access key. When editing an existing connection, leaving the secret blank preserves the saved secret; it does not clear it. Credential replacement is verified against the provider before it is accepted.
Open Synchronization. Review Synchronize organizations and Synchronize devices. These preferences are saved, but the current Core processor processes both organizations and devices without applying the flags. Do not rely on clearing them to protect a set of records from synchronization. If selective synchronization is required, resolve that requirement with the integration owner before running.
Open Alerts. Under Create cases for, select the intended Critical, Major, Moderate and/or Minor severities. Choose the intended Division and Queue.
Review Priority with the administrator: this saved field is retained for compatibility. Generated alert cases use the alert severity mapping, so do not assume this dropdown overrides every alert’s effective priority.
Open Notifications. Set New device recipients and Synchronization error recipients to approved monitored addresses. The page supports multiple email addresses.
Save the settings using the settings workspace save action. Read the result, reopen the settings and confirm the intended choices remain saved.
Use Synchronize now when you are ready for a full organization/device refresh (alerts still use the saved cursor), then inspect Audit and representative records as described below.

Verify organizations, assets and alert cases separately

Scheduled synchronization follows the established two-hour service cycle; it is not a real-time delivery promise. Synchronize now refreshes organizations and devices, bypassing the device last-synchronization filter. Alert retrieval still starts from the saved alert cursor; it does not replay the entire alert history. The synchronization processes organizations, devices and alerts in phases. A later failure does not guarantee that earlier changes were rolled back, so inspect the result before repeating the operation.

Open Audit. Review Last synchronization, Consecutive errors and Last alert cursor. Compare them with the operation you just requested.
Open a representative Company and confirm it corresponds to the expected provider organization. A similar display name is not enough when customers have multiple sites or related companies.
Open a representative asset. Check its customer association and available imported device details such as manufacturer, model, serial number, type and provider device link. Generated fields use NJ-prefixed names, including provider IDs.
Using the controlled selected-severity alert, locate the resulting case. Confirm its Company/device relationship, division, final owner/queue, priority and workflow results.
Verify the case audience before communicating with the customer. Generated alert cases are private; decide deliberately what approved information should become customer-facing.
Test an unselected severity as part of the controlled acceptance plan. Confirm your expectations without changing every severity just to force a case to appear.

If a case is assigned differently from the saved integration default, review the workflow and routing history before changing the integration. The default is one input to the support process, not a guarantee that no later rule can affect the case.

Work a monitored-device incident with full customer context

Example: recurring equipment alarms at a customer site

A monitored device generates an actionable alert. The agent checks the mapped customer and asset, reads previous cases for that equipment and determines whether the alarm is a new failure or part of an existing investigation. The agent records verified findings, the next action and an accountable owner. If the issue needs engineering involvement, the case’s escalation process keeps the customer commitment visible while the technical team investigates.

Confirm the provider alert and actual device state before diagnosing from the alert title alone.
Check whether related cases already explain the event, and coordinate with their owners to avoid conflicting customer instructions.
Review the customer’s service commitments and any escalation requirement. Monitoring severity and support priority are related operational inputs, not necessarily the same contractual classification.
Keep internal technical details in the appropriate activity and send a clear customer update through an approved public communication path when needed.
Before closing, record what was fixed or why no action was required and verify the relevant device condition. Then check the provider alert-reset result separately.

Understand alert reset after a case closes

Closing the linked Supportbench case does not immediately reset the provider alert. During background processing, the integration looks for linked cases closed within the preceding six hours and requests the provider’s alert reset/delete operation. Verify the provider result after a successful synchronization; do not use case closure alone as proof that the monitoring console is clear.

If synchronization was failing or unavailable across that window, an older closed case may not be picked up by the normal recent-closure check. Have the integration owner review the provider alert and appropriate recovery action. Reopening and closing customer cases repeatedly is not a reliable integration repair process.

A cleared monitoring alert also does not prove that every customer symptom has been resolved. Close the support loop using the actual investigation and agreed acceptance criteria.

Maintain the connection and handle removal deliberately

Record the current synchronization-checkbox mismatch with the integration owner so it remains visible during future product changes. Review connection health as part of the team’s operating routine, especially after credential, provider-access or routing changes. Investigate repeated errors and compare imported records with current provider data. A recent timestamp is useful evidence, but inspect the phase and representative records when a synchronization reports partial failure.

Uninstall NinjaRMM removes the integration’s custom Fields and their Field Data and disables its generated Activity Type. Existing Companies, assets and cases remain. This is a consequential configuration removal, not a pause button or a first troubleshooting step. Review the displayed consequences, preserve needed operational evidence and coordinate the change with the integration owner before confirming it.

Troubleshoot the symptom you can observe

Symptom	Check next
New credentials are rejected	Confirm v1/HMAC compatibility and the intended provider installation. Current OAuth credentials are not a substitute for the required key pair.
The secret input is blank	A blank field with an existing saved secret is expected during editing; it preserves the saved value. Do not replace a working secret because it is not displayed.
Devices appear but some other data is missing	Inspect customer mapping and phase/error results. The saved organization/device checkboxes do not gate current processing. A pass can partly commit before a later phase fails.
No new alert case appears	Check selected severities, synchronization health, alert cursor and whether the alert has already been mapped. Empty severity selection intentionally creates no new alert cases.
The case has an unexpected priority	Review alert-severity mapping and subsequent workflows; the compatibility Priority field is not an unconditional override.
The customer cannot see the alert case	Generated cases are private. Review the intended communication/access process before broadening visibility.
A closed case still has an active provider alert	Check successful background synchronization, the recent six-hour closure window and the provider reset result.
Needs attention or consecutive errors persist	Give the integration owner non-secret status, timing and representative IDs. Investigate compatibility and the reported failure before repeated full refreshes.

Was this article helpful?