Help center Core configuration Integrations & migrations Configure NinjaRMM synchronization and alerts Updated Wednesday, October 28, 2026 · Marc Staine NinjaRMM can synchronize organizations and devices and create support cases for selected alert severities. Routing and notification choices let operational teams receive relevant work without enabling every alert. Applies to: Supportbench Core. Location: Settings → Integrations → NinjaRMM. Access and available controls depend on your role and account capabilities. Confirm provider credential compatibility firstThe current Core connector uses NinjaRMM v1 access-key and secret-key authentication. NinjaOne’s current public API documentation describes API 2.0 and OAuth2; those credentials are not interchangeable. Before a new connection or credential replacement, confirm compatible v1 access with Supportbench and the provider. Do not substitute an OAuth client secret or token into the Access key / Secret access key fields. Provider requirements reviewed on 28 October 2026; see the NinjaRMM operations and compatibility guide.Inspect the actual outcome: scheduled synchronization follows the established two-hour service cycle; Synchronize now refreshes organizations/devices, bypassing the device last-synchronization filter; alerts still use the saved cursor and are not replayed from the beginning. Processing can commit organizations, devices and alerts in separate phases, so a later failure does not prove earlier changes were rolled back. The saved Priority field is retained for compatibility; generated alert cases use alert-severity mapping and may be affected by workflows. Verify final customer, asset, owner, priority and visibility.Closure is asynchronous: background synchronization requests provider alert reset for linked cases closed within the preceding six hours. Case closure alone does not prove that the provider alert has reset. Investigate missed synchronization windows with the integration owner rather than repeatedly reopening and closing cases.Synchronization checkbox limitation: Core saves Synchronize organizations and Synchronize devices, but its current processor does not apply those flags and processes both. Clearing a checkbox is not a way to stop the corresponding import. Confirm the actual scope with the integration owner before running; track the UI/runtime mismatch separately from documentation publication.Before you begin Confirm you can administer integrations and have access to the intended provider workspace.Record the existing connection and routing choices. Use a representative test record before enabling broad synchronization.Obtain credentials through your approved provider process; do not place secrets in articles, screenshots or support messages. Configure and verify Open this integration from Settings → Integrations.Review the connection identity and enter only the provider details requested by the page.Choose the available synchronization, routing or activity options described below.Save settings and use the displayed verification action when available.Inspect one representative record on both sides and review the integration status before relying on automated processing. Settings reference Connection and operating controlsSettingWhat it controlsHow to chooseAccess key / Secret access keyCompatible NinjaRMM v1 credentials. A blank secret preserves the existing saved secret; new or replaced credentials are verified.Confirm credential compatibility before setup or replacement. Keep keys out of copied diagnostics.Synchronize organizations / Synchronize devicesStores organization/device preferences. The current Core processor still processes both entities without applying these flags.Do not rely on these checkboxes to limit imports. Confirm that processing both organizations and devices is acceptable, or resolve selective-sync requirements before running.Synchronize nowRefreshes organizations/devices; alert retrieval remains incremental from the saved cursor. Scheduled synchronization follows the established two-hour service cycle.Review mapping and routing before refreshing organizations/devices; this action does not replay historical alerts.Critical / Major / Moderate / MinorSelects which alert severities create cases. No selection means no new alert cases.Start with actionable severities.Division / Priority / QueueDivision and Queue provide routing defaults. Priority remains available for compatibility; generated cases use alert-severity mapping.Use a monitored queue and inspect final division, owner, priority and workflow results on a controlled alert case.New device recipients / Synchronization error recipientsMultiple notification addresses for new devices and repeated failures.Use operational mailboxes with clear ownership.AuditLast synchronization, error count, alert cursor and creation/modification information.Use these to distinguish a quiet system from a failing integration.UninstallRemoves integration configuration/custom-field data and disables its generated activity type; existing companies, assets and cases remain.Review the displayed consequences before uninstalling. Behavior to knowGenerated alert cases are private. Review their audience before sharing them. Recommended use Enable only the flows your support process needs and identify an owner for connection failures.Test mappings and routing with representative records before broad use. Review existing data before a resynchronization or removal. Worked example Configure the provider keys.Enable organizations/devices and only the required alert severities.Choose routing and notification recipients, save, then synchronize.Inspect representative records and a controlled alert case. Troubleshooting ProblemWhat to checkThe item is missing from a picker.Check Active, division access, parent hierarchy, enabled modules, and the user’s role. Reopen the consuming form after saving.The form rejects a save.Read the displayed validation message. Check required values, text limits and permitted scope; do not change unrelated settings to bypass validation.An existing record still shows an old value.A configuration change and a record change are different operations. Inspect the record and relevant references before assuming the save failed. Related configuration Integrations → Use the data synchronization logOrganization → Configure agent roles and division accessFor additional setup and usage context, see these related guides:NinjaRMM Integration Was this article helpful? Yes No Thank you for your feedback.