Automate inventory updates

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.

How inventory population works

Each time you run a Populate Inventory task, Inventory Manager:

Clears the existing inventory entirely.
Replaces it with the full node list provided in that run.
Removes any node not included in the current run.

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.

Build a sync workflow

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.

Step 1: Retrieve the complete device list

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:

The query must return the complete target device list, not a delta or recent changes only.
If your source of truth paginates results (common in large environments), your workflow must loop through all pages and aggregate the full list before proceeding. A child workflow or loop construct in Studio handles this cleanly.
Filter results at this stage if needed—for example, query only active devices, or only devices assigned to a specific region or device type.

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.

Step 2: Transform the data

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:

Attribute	Example value	Description
`itential_host`	`10.1.1.5`	Device IP address or hostname
`itential_user`	`admin`	Username for device authentication
`itential_password`	`$SECRET_vault$KEY_devicepass`	Reference to Secrets Manager—never store passwords in plaintext
`itential_platform`	`cisco_xr`	Device platform type—determines Config Manager grouping
`itential_driver`	`netmiko`	Connection driver: `netmiko` or `scrapli`
`itential_port`	`22`	SSH port—typically 22

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.

Step 3: Populate the inventory

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.

Example: Netbox sync workflow structure

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.

Parent workflow: Sync All Inventories
  │
  ├─ Get all active sites from Netbox (getDcimSites)
  │
  └─ For each site → call child workflow: Sync Site Inventory
        │
        ├─ Get Device Netbox Inventory (child — handles pagination)
        │     └─ Loop: call getDcimDevices with offset until all pages retrieved
        │
        ├─ Transform: apply Jinja2 template (Netbox format → node attributes)
        │
        └─ Populate Inventory (atomic replace for this site's inventory)

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.

Schedule your sync workflow

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.

Set up a schedule trigger in Operations Manager

Navigate to Operations Manager in Itential Platform.
Select Automations from the left navigation.
Create a new automation and choose Schedule as the trigger type.
Select your inventory sync workflow as the target.
Configure the trigger schedule.
Enable the automation. Operations Manager executes the workflow on your defined schedule.

Alternative trigger types

A schedule trigger works for most environments, but Operations Manager supports three additional trigger types that may better fit your use case:

Trigger type	How it works	Best suited for
Manual	An operator executes the workflow on demand from Operations Manager.	Initial population, ad-hoc refreshes, testing
API	An external system calls an Platform API endpoint to trigger the workflow.	Provisioning workflows that add a device and immediately need it in inventory; CMDB systems that can call an outbound webhook on change
Event	The workflow fires in response to an internal Platform event (e.g., a job completing, an adapter state change).	Chaining inventory sync at the end of a provisioning workflow automatically
Schedule	The workflow runs on a recurring schedule.	Routine synchronization from an external source of truth on a defined cadence

Choose the right trigger for your environment

Your environment	Recommended trigger	Sync cadence
Stable device inventory, changes infrequent	Schedule trigger (daily/nightly)	Daily—run during a maintenance window
Devices added via provisioning workflows	API or event trigger at the end of each provisioning workflow	On-demand—triggered by the provisioning event
External CMDB pushes changes via webhook	Event trigger listening for the webhook	Real-time—inventory syncs when source changes
Multiple sources of truth (by device type or region)	One schedule trigger per sync workflow	Each inventory on its own appropriate cadence
Ad-hoc or initial population	Manual trigger	On-demand as needed

Manage large inventories

Environments with tens of thousands of nodes are fully supported. A few design considerations keep sync workflows performant and reliable:

Handle pagination in your retrieval step. Most external systems (ServiceNow, SolarWinds, Netbox) paginate API responses. Your workflow must loop through all pages and aggregate the complete list before calling Populate Inventory. A dedicated child workflow for retrieval and pagination keeps the logic reusable across multiple parent workflows.
Split large inventories by device type or region rather than creating one inventory with all devices. This keeps individual sync runs faster, scopes RBAC correctly, and simplifies IAG5 service configuration.
Review Job Manager output after each sync run to verify the node count matches expectations and no device creation failures occurred.

Next steps

To implement an automated inventory sync:

Identify your authoritative inventory source and confirm API access credentials.
Build your sync workflow in Studio following the three-phase pattern above.
Test the workflow manually using the manual trigger in Operations Manager to validate output before scheduling.
Configure a schedule trigger in Operations Manager appropriate for your environment.
Monitor the first several automated runs via Job Manager to confirm successful execution and accurate node counts.

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.