/warranty-tracking

name: "Warranty Tracking"
description: >
  Endpoint hardware warranty status across whatever RMM platforms (Datto RMM,
  NinjaOne, N-central, Kaseya VSA, ConnectWise Automate, Atera, SuperOps, Syncro,
  Action1, ImmyBot) and documentation tools (IT Glue, Hudu) are connected: the
  reliability spread between OEM-resolved and hand-entered warranty fields,
  serial/asset-tag cross-referencing when RMM data is missing or stale, and the
  expired / expiring-soon / covered / unknown bucketing.
when_to_use: >-
  When pulling, normalizing, or auditing hardware warranty status across
  connected RMM platforms and documentation tools. Use when: warranty
  status, warranty audit, expired warranty, warranty expiring, is this
  device under warranty, warranty check, out of warranty devices.

Warranty Tracking

Overview

Warranty status is the single-most load-bearing field in hardware asset management and the least consistently reliable one across RMM platforms. Some RMMs resolve warranty directly from the OEM (serial-number lookup against Dell/HP/Lenovo warranty APIs) and refresh it automatically. Others expose a warranty field that is purely a manually-entered value someone typed in once during onboarding and never touched again. Treating both as equally trustworthy produces confident-sounding reports built on stale data. This skill covers how to pull warranty data across whatever RMM(s) an org has connected, how to weigh its reliability, and how to fall back to documentation platforms (IT Glue, Hudu) when RMM data is missing or looks stale.

This is endpoint/hardware warranty specifically — physical device coverage status. It is not network/cloud infrastructure health (see `cloudops-pack`) and it is not a service-desk ticket about a broken device (see `ops-pack`); a device can be fully healthy and in active use while still being three weeks from warranty expiration, which is exactly the case this skill exists to catch before it becomes a support problem.

Anti-triggers

• **One platform's own warranty or lifecycle field** — "what does Auvik

return for warranty," "read N-central's lifecycle record" is that connector's API surface; use `auvik-devices` or `ncentral-devices`.

• **ScalePad Lifecycle Manager's warranty product** — LM holds its own

hardware lifecycle records and warranty pricing; use `scalepad-lifecycle-manager` for anything scoped to that tool.

• **Looking up one asset's record** — use `itglue-configurations` or

`hudu-assets`; this skill sweeps warranty state across a fleet.

Discovering available tools first

Never assume which RMM or documentation platform is connected:

1. Call `conduit__search_tools` with a query like `"device warranty"`, `"list devices"`, or `"device lifecycle"` to discover which RMM connector(s) are actually live for this org and their real tool names (e.g. `datto-rmm__datto_list_devices`, `ninjaone__list_devices`, `ncentral__ncentral_get_device_lifecycle`, `kaseya-vsa__list_devices`). 2. More than one RMM can be connected (a portfolio spanning multiple clients on different platforms, or a client mid-migration between RMMs). Cover all connected platforms; don't stop at the first. 3. Separately discover documentation platforms (`itglue__search_configurations`, `hudu__*` equivalents) as an optional fallback source, not a primary one — RMM inventory is the source of truth for "what devices exist"; documentation is the source of truth only when the RMM's own warranty field is empty or stale. 4. Only call concrete tools that discovery actually returned.

Key Concepts

Warranty data reliability varies by RMM

Different RMM platforms expose warranty with materially different trustworthiness. Do not treat every non-null warranty field as equally current:

| Signal | What it means | |---|---| | Warranty field populated with a specific expiry date, refreshed automatically from OEM lookup (where the connected RMM supports it, e.g. serial-based Dell/HP/Lenovo API resolution) | High confidence — treat as authoritative | | Warranty field populated but the RMM has no automated OEM refresh mechanism, or the field was clearly hand-entered (e.g. N-central's lifecycle record, which is explicitly a human-maintained field) | Medium confidence — usable, but flag as "manually maintained, verify if action-critical" rather than presenting it with the same certainty as an OEM-sourced date | | Warranty field empty or null | No confidence — this is a coverage gap, not a "no warranty" finding. Report it as "warranty unknown," never as "out of warranty" | | Device present in RMM inventory with no lifecycle/warranty record at all | Worst case — an untracked device is a hidden risk. Surface it explicitly rather than silently omitting it from the report |

Never infer "out of warranty" from an empty field. An empty field means the data wasn't captured, not that coverage lapsed — conflating the two produces false alarms that erode trust in the report.

Cross-referencing documentation platforms

When RMM warranty data is missing or looks stale (e.g., unchanged for multiple audit cycles, or a purchase date that doesn't match the device's first-seen date in the RMM), check whether the org has IT Glue or Hudu connected and search for a matching asset/configuration record there:

1. Match by serial number or asset tag first — the most reliable join key across platforms. 2. If the documentation platform has a warranty or purchase-date field for the matched asset, use it to fill the gap, and note in the report that the figure came from documentation rather than the RMM. 3. If neither source has the data, report the device as "warranty unknown — not tracked in RMM or documentation" rather than omitting it. An unknown is itself a finding worth surfacing, especially for servers and other high-criticality devices.

Expiring vs. expired

Bucket every device into one of three states, not a binary "in/out of warranty":