Inventory module

Every machine. In the ticket.

Top-level Inventory page lists every managed machine across integrations. Hardware specs, security posture, linked user, linked company, installed software, ticket history. Module shipped against Action1* as the reference adapter — schema + sync pipeline are RMM-agnostic, so additional RMMs (Zabbix inventory, NinjaOne, Datto, ConnectWise) drop in through the same integration registry.

Up to date Reboot required 3 critical patches
Asset types

Twelve seeded. Customs for the rest.

Each type controls which built-in fields apply — monitors don't need a hostname, printers do, VoIP phones get extension + PC-pass-through MAC. Admin can define custom asset types for the long tail (door readers, NVRs, signage displays) without code changes.

WorkstationServerLaptopPrinterMonitorVoIP phoneNetwork switchWireless APMobileUPSNVR/DVROther
Action1 connector* — reference adapter

One source. Alerts + inventory + software.

Resolvd polls Action1's v3 REST API with an OAuth2 client-credentials key. Token-bucket rate limiting + 429 retry-after handling. Toggle Feed inventory module on the alert source to enable the inventory paths.

Action1 was the shipping target because the v3 REST API is well-documented and exposes every signal Resolvd cares about in one place. The poll pipeline below documents the Action1 path specifically — any RMM that exposes endpoints + policy results + installed software can plug into the same write paths via a registry adapter.

GET /api/3.0/organizations

Tenant org IDs — one Action1 source can fan out across many orgs.

GET /policies/instances/{org}/{policy}/endpoint_results

Failed policy runs — each becomes a ticket on the matching alert rule.

GET /api/3.0/endpoints/managed/{org}/{ep}

Hardware specs + last-logged-in user + security posture (patches, vulns, reboot required).

GET /api/3.0/apps/{org}/data/{ep}

Installed software inventory. Polled on demand + every 7 days via the scheduler, 2 stale computer-type assets per tick.

Security posture

First-class. Not buried in raw_data.

Action1 reports patch + vulnerability counters in every endpoint payload. Previously they sat unused; now they're first-class columns. The inventory list gets Patches + Vulns columns with red badges for non-zero criticals. Existing assets get backfilled on upgrade — no re-poll needed.

missing_updates

Critical / other counts. Red badge on non-zero criticals.

vulnerabilities

Critical / other counts. Same badge treatment.

update_status

SUCCESS / WARNING / ERROR. Color-coded inline.

reboot_required

Bool flag. Inventory list filter chip when on.

Installed software

Per-asset. Searchable. Auto-pruned.

Per-asset software inventory pulled from Action1 on demand (Sync now button) and automatically every 7 days. The scheduler picks 2 stale computer-type assets per tick to keep API load light. Re-syncs drop uninstalled packages automatically — the list reflects the device state, not stale history.

Search by name or vendor across the installed list. A workspace-level software aliases table maps vendor-specific names (Microsoft 365 Apps for Enterprise / M365 Apps / Office 365) to a canonical product so reports don't fragment per vendor.

Custom fields

Stable slugs. Rename-proof.

Custom fields per entity with stable slugs that survive label renames. Asset Tag is the canonical example — define once, fill on every asset. Five field types:

textnumberdateboolselect

Action1's 30 per-endpoint custom attributes can route to either an asset column or a custom field via a per-source mapping table. Each attribute slot's most-recent sample value renders inline so admins map against real data, not guesses.

Ticket ↔ asset linking

Linked both ways. MSP-safe.

Asset detail pages show ticket history; ticket sidebars show the linked asset's hostname (clickable). Per-project toggle gates this — off by default, on requires explicit opt-in plus an optional company filter that restricts the picker to specific Resolvd companies. MSP isolation: customer A's project never sees customer B's assets.

UPN auto-association

Action1 reports each endpoint's last-logged-in user as a plain string (jdoe, stratus-admin). On every sync, Resolvd's UPN matcher generates plausible aliases from each user's display name + email local part — for "John Doe": johndoe, jdoe, johnd, john, doe, doej — and matches against what the RMM reports. Ambiguous matches refuse to guess; admin can manually link via the asset detail UI.

Company resolution

Three strategies for tenant routing.

Org names in the RMM rarely line up with Resolvd companies one-to-one. Three knobs cover the common MSP shapes:

Exact name match

Default — Action1 org names that line up with Resolvd companies resolve automatically.

Per-source company map

Multi-tenant integrations where org names don't match (Stratus Systems — HQ, Stratus Systems — DC2). Admin routes each exotic name explicitly.

Inventory company override

Single-tenant sources (one Zabbix per customer) — pin the entire source to one company in one click.

Other RMMs

Action1 first. Not Action1 only.

Asset schema, custom-field router, UPN matcher, company resolution, security-posture columns, and software sync all sit behind RMM-agnostic write paths. Action1 happens to be the first adapter to wire them up end-to-end — the inventory module itself doesn't assume anything Action1-specific.

services/integrations/registry.js is the entry point for new adapters. Implement pollEndpoints() + pollSoftware() against the vendor's API and the add-source UI renders the credentials form from your credentialsSchema.

Roadmap
Next
Zabbix inventory pull

Same pattern as Action1, scoped to single-customer sources for MSP isolation.

Next
Phase 2 multi-source dedup

Drag-drop priority list + fill_gaps / dedupe_only strategies when two RMMs report the same machine. Parked until adapter #2 lands.

Open
NinjaOne · Datto · ConnectWise

No registry entry yet. Open an issue if you'd contribute one.

Hook up your RMM.

Admin → Alert sources → New. Pick Action1 (or any other registered adapter), paste credentials, toggle Feed inventory. Endpoints populate on the first poll.

* This integration is an independent community project and is not affiliated with, endorsed by, sponsored by, or supported by Action1 Corporation. Action1 has not reviewed, tested, certified, or audited this integration for security, performance, or compliance purposes and is not responsible for its operation, availability, or use. “Action1” is a trademark of Action1 Corporation and is used solely to identify compatibility with the Action1 platform.