NinjaOne

This guide walks you through connecting your NinjaOne tenant to Clarion. Once connected, Clarion turns NinjaOne’s triggered conditions into issues your agents can triage, and gives those agents read-only lookups across every managed device.

​

Prerequisites

• Access to your NinjaOne instance as a system administrator
• A Clarion workspace with the NinjaOne integration open
• For the OAuth method, a NinjaOne technician account the connection will run as

---

​

Step 1 — Choose an authentication method

Clarion connects to NinjaOne one of two ways. Pick before you create the app, because the Application platform you choose in NinjaOne decides which grant types the app can use — and a machine-to-machine app cannot run scripts no matter what it is granted. API services is the default and what every existing connection uses. Choose Web application if you want agents to run scripts from your automation library.

---

​

Step 2 — Create the app in NinjaOne

1. In NinjaOne, go to Administration → Apps → API.
2. Open the Client app IDs tab and click Add.
3. Set Application platform first — NinjaOne pre-fills the rest from it:

   Method	Application platform	Allowed grant types	Redirect URIs
   API services	API Services (machine to machine)	Client credentials	not used
   Web application	Web (PHP, Java, .Net Core, etc.)	Authorization code, Client credentials and Refresh token	the Callback URL Clarion shows

4. Under Scopes, select Monitoring and Management. Management is only needed for device actions, but it costs nothing to grant now and adding it later means editing the app. Clarion never asks for Control, so it cannot start remote sessions either way.
5. Under Allowed grant types, select the ones for your method from the table above.
6. On the Web platform, Redirect URIs is required: paste the Callback URL from Clarion’s connect form exactly as shown.
7. Save, then copy the Client ID and Client Secret.

---

​

Step 3 — Connect in Clarion

1. In Clarion, open the NinjaOne integration from your workspace settings.
2. Choose the Authentication method you created the app for.
3. Choose your Region. This is the NinjaOne instance you sign in to — for example app.ninjarmm.com for the United States or eu.ninjarmm.com for Europe. Credentials issued in one region will not work against another.
4. Paste the Client ID and Client Secret.
5. API services: click Connect. Clarion verifies the credentials against NinjaOne before saving them, so a mistyped secret or the wrong region is reported straight away. Web application: click Authorize with NinjaOne and sign in as the technician the connection should run as. The connection is not live until that finishes.

You can change methods later from the connected view — it is the same form, and your organization scope, ingestion mode and device-action setting are kept.

---

​

Step 4 — Add a NinjaOne monitor

The integration on its own gives your agents device lookups. To turn NinjaOne’s triggered conditions into Clarion issues, add a NinjaOne monitor:

1. Open the agent you want to receive NinjaOne conditions.
2. Add a NinjaOne monitor.
3. Optionally narrow what gets ingested:
   • Severity filter — leave everything selected to ingest every severity. Unchecked severities are dropped before an issue is created.
   • Organizations — a comma-separated list of NinjaOne organization IDs. Leave it empty to cover the whole tenant.

Only triggered conditions become issues. The rest of NinjaOne’s activity log — job progress, policy edits, condition resets — is not turned into issues, though your agents can still read it per device.

---

​

Step 5 — Choose how conditions reach Clarion

Under Ingestion on the integration page you can pick one of two delivery methods. Polling (default). Clarion checks NinjaOne every minute for new triggered conditions. Nothing to configure, and it works on any tenant. Webhook. NinjaOne pushes each triggered condition to Clarion the moment it fires, which removes the polling delay. Turning the switch on registers the webhook in NinjaOne for you. Switching back to polling deregisters the webhook in NinjaOne automatically.

---

​

Step 6 (optional) — Device actions

By default agents can only read from NinjaOne. Device actions lets them also change something on a machine: run a script from your automation library, start/stop/restart a Windows service, or start a patch scan or apply. To enable it:

1. Make sure your NinjaOne app has the Management scope (Administration → Apps → API).
2. In Clarion, open the NinjaOne integration and turn on Allow scripts, service control and patch jobs under Device actions.

Clarion checks that the app actually grants Management before storing the setting, so an app still limited to Monitoring is rejected there and then rather than failing later during an investigation. Running scripts additionally requires the Web application (OAuth) method from Step 1 — service control and patch jobs work either way. On that method, the technician who authorized needs permission for the automation categories of the scripts your agents run; if a script belongs to several categories, they need all of them. NinjaOne accepts these without reporting what they did, so agents confirm the outcome afterwards by reading the device’s activity log — a submitted action is never reported as a completed one. Turning the switch back off takes effect immediately and never calls NinjaOne, so it works even when NinjaOne is unreachable.

---

​

Step 7 (optional) — The ClarionBot script

Device actions let an agent run a script that is already in your automation library. ClarionBot is the other half: one library entry that lets an agent run a PowerShell command it composed for the investigation — read a log file, check a registry value, run a diagnostic cmdlet — and get the output back in the same call. It is one script, created once per NinjaOne tenant. Clarion looks it up by name every time it runs, so the ID NinjaOne assigns it can differ between your environments and nothing has to be configured in Clarion. It builds on the two steps above and needs both: Device actions turned on (Step 6), and the Web application (OAuth) method (Step 1), because NinjaOne refuses every script run that is not made on behalf of a technician.

​

Create the script

1. In NinjaOne, go to Administration → Library → Automation.
2. Click Add → New Script.
3. Paste this as the script body:
   Param(
       [Parameter(Mandatory=$true)]
       [string]$code
   )
   
   $bytes = [System.Convert]::FromBase64String($code)
   $DecodedCommand = [System.Text.Encoding]::UTF8.GetString($bytes)
   
   # Execute Script Content
   iex $DecodedCommand
   
   Write-Host "Ephemeral Agent started"
   
4. Set the script’s properties:

   Field	Value
   Name	ClarionBot
   Language	PowerShell
   Operating System	Windows
   Architecture	All
   Run As	System

   The name has to be exactly ClarionBot — that is what Clarion resolves. Capitalisation and surrounding spaces do not matter, but a second script by the same name does: Clarion refuses to guess between them.
5. Before leaving the script, add the script variable the parameter needs:
   1. Click + Add next to Script Variables.
   2. Select the String/Text type.
   3. Enter Code as the variable name.
   4. Click Add.
6. Save the script.

You do not need to note the script ID, and you do not need to configure anything on the endpoints. Running as System needs nothing beyond the NinjaOne agent already being installed, and no credential has to exist in NinjaOne’s credential store.

​

Check it works

Ask an agent to run whoami on a Windows device and approve the call. A working setup answers nt authority\system followed by Ephemeral Agent started.

---

​

What your agents can do

With NinjaOne connected, agents triaging any issue — not only NinjaOne ones — can look up:

• Devices — search by hostname, or list with a NinjaOne device filter
• Device detail — OS, organization and location, approval status, and last check-in
• System — manufacturer, model, serial, memory, OS build, last boot, pending reboot, CPUs, and your custom fields
• Health — NinjaOne’s own health rollup for a device
• Antivirus — installed product, its reported state, definition freshness, and detected threats
• Patching — applicable OS and software patches and their install state
• Software — installed applications and versions
• Services — Windows service state and start type, filterable by service name
• Storage — disks, volumes, free space, and SMART status
• Network — interfaces and the last logged-on user
• Users and access — which end users are entitled to a device, and who last logged on
• Tickets — service and access requests from your NinjaOne ticketing boards, with their comment history
• Conditions — what is currently firing, on one device or across the tenant
• Fleet reports — any of NinjaOne’s inventory reports run across every device in scope, which is how an agent tells a single failing host from an estate-wide problem
• Jobs and activity — what is running on a device now, and what ran recently
• Vulnerability scan imports — which third-party vulnerability feeds this tenant imports, and whether the last import succeeded. These are import pipelines rather than per-device findings, which NinjaOne’s API does not expose; a workspace restricted to specific organizations sees none of them, because a scan group names no organization.

All of the above are read-only. If you enabled Device actions, agents can additionally control a Windows service and start a patch scan or apply — and, on the OAuth method, run a script — each behind a human approval. With the ClarionBot script in your library they can also run a PowerShell command they composed for the investigation and read its output.

---

​

Troubleshooting

“NinjaOne rejected these credentials.” The client ID or secret is wrong, or the region does not match the instance you sign in to. Check the region first — it is the most common cause. “These credentials were accepted but lack the monitoring scope.” Edit the app in Administration → Apps → API and add the Monitoring scope. “This NinjaOne app does not grant the management scope.” You tried to enable Device actions with an app limited to Monitoring. Add the Management scope in Administration → Apps → API, then connect again. Reads are unaffected in the meantime. “NinjaOne refused this action because it has to run as a NinjaOne user.” The workspace is on the API services method, which has no user behind it. Reconnect with the Web application (OAuth) method. Adding scopes will not fix this — NinjaOne’s machine-to-machine documentation says Management covers running scripts, but the API enforces a user context regardless. “NinjaOne no longer accepts Clarion’s authorization.” On the OAuth method: the grant was revoked, the app was deleted, or its secret was rotated. Reconnect and authorize again. Reads stop too, since everything runs under that grant. “NinjaOne did not return a refresh token.” The Web app is missing the Refresh Token grant type. Add it in Administration → Apps → API and authorize again. “This NinjaOne tenant has no automation script named ClarionBot.” The wrapper script has not been created, or it is named something else. See Step 7. Clarion matches the name ignoring case and surrounding spaces, but nothing else — Clarion Bot and ClarionBot-v2 will not resolve. “This NinjaOne tenant has N automation scripts named ClarionBot.” Two library entries share the name, and picking one would be a guess. Rename or delete the duplicates so exactly one remains. “Unable to retrieved credential information.” NinjaOne reports this on a run when it is asked to use a credential role the tenant has not defined. Clarion always runs ClarionBot as System and never names a role, so this points at a different automation — check what else ran on the device around the same time. A run returns running rather than output. The command is still executing on the device; it is not a failure and re-running it would execute it twice. The agent can read the device’s activity log afterwards to pick up the result. Raise the wait if the commands you expect routinely take longer. No issues appearing. Confirm a NinjaOne monitor exists and is attached to an agent, that the condition you expect is actually firing in NinjaOne, and that its severity is not excluded by the monitor’s severity filter. Conditions from the wrong customers. Set the monitor’s Organizations filter to the organization IDs this workspace should cover.