Inventory Manager federates data from your authoritative inventory sources—tools like ServiceNow, SolarWinds, Netbox, or a CMDB—into a single, automation-ready interface. Inventory population is an atomic operation: every time you populate an inventory, Inventory Manager clears the existing contents and replaces them with the nodes you provide. Any node not included in the current run is removed, so your inventory always reflects a complete, accurate snapshot of your source of truth.
Because every populate operation requires your complete intended node list (not just additions or changes), the most effective approach at scale is to automate the sync so that running it against thousands of nodes requires no more effort than running it against 10.
If your team regularly adds inventory devices manually in Inventory Manager, consider whether a workflow-driven sync from your authoritative source would reduce that overhead and improve accuracy.
Each time you run a Populate Inventory task, Inventory Manager:
Because this is a full-replace operation, the sync workflow must retrieve the complete device list from your source of truth on every execution—not just the delta. For more information, see Create and populate inventories.
An inventory sync workflow follows a consistent three-phase pattern regardless of which source of truth you pull from. You build the workflow in Studio.
Query your source of truth for every device that should be present in the inventory after the sync. You typically do this using an adapter task or HTTP request task that calls your system’s API.
Key requirements:
Split large inventories by device type or region rather than creating one inventory with all devices. This simplifies the IAG5 services that execute against those devices and makes the sync query more targeted.
Your source of truth almost certainly stores device data in a different format than Inventory Manager expects. A transformation step maps source fields to the node attributes your inventory requires.
At minimum, each node must include the following attributes when used with IAG5 Net SDK services:
Itential Platform’s built-in transformation capabilities (JST transformations or Jinja2 templates) are the recommended approach for this mapping. A Jinja2 template is particularly useful when platform slugs from your source of truth need to be translated to IAG5 values—for example, mapping a Netbox platform slug of cisco_ios-xe to the IAG5 value ios.
Call the Populate Inventory task with the fully transformed, complete node list. This atomic step replaces the current inventory contents.
The task accepts the list of nodes and the target inventory name. On successful completion, the inventory reflects exactly the nodes you provided—no more, no less.
The following structure illustrates how a multi-site Netbox-to-IAG5 sync workflow might be organized. Adapt this pattern to your own source of truth and inventory design.
If your environment has many sites or device types, use a parent-child workflow pattern. The parent orchestrates iteration across sites or groups, and a reusable child workflow handles the actual sync logic for each.
Once your sync workflow is built and tested, you can automate it to run on a recurring basis using Operations Manager. This eliminates manual execution and keeps your inventory current without intervention.
A schedule trigger works for most environments, but Operations Manager supports three additional trigger types that may better fit your use case:
Environments with tens of thousands of nodes are fully supported. A few design considerations keep sync workflows performant and reliable:
To implement an automated inventory sync:
For assistance building integration adapters for your specific source of truth system (ServiceNow, SolarWinds, Netbox, or custom CMDBs), see the Itential Adapter documentation or contact your Itential representative.