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 Automation 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 Automation 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 schedule using a cron expression. For example:
| Cron expression | When it runs | When to use it |
|---|---|---|
0 2 * * * |
Daily at 2:00 AM | Most environments—stable inventory, nightly refresh |
0 */4 * * * |
Every 4 hours | Environments where device changes are frequent |
0 1 * * 0 |
Weekly, Sunday at 1:00 AM | Very stable inventories with infrequent changes |
0 22 * * 1-5 |
Weekdays at 10:00 PM | Environments with maintenance window constraints |
- 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 cron-defined 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 with a cron expression 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), refer to the Itential Adapter Builder documentation or contact your Itential representative.