Your Infrastructure Record, Now Native in Jira Service Management Assets

The NetBox Labs Jira Assets Integration is generally available, with the full 28-type schema provisioned for you.

Teams often keep their infrastructure data in one system and their service workflows in another. That creates a simple problem: the people approving or working a ticket can’t always see the infrastructure context they need.

A change request names a switch in free text. The approver cannot see what sits behind it, so the ticket goes back to an engineer who opens the NetBox Labs platform, finds the rack and the site, checks which addresses are involved, and pastes the answer into Jira. Then the next change request starts it over. The authoritative record sits in one system and the workflow that changes it sits in another, so every ticket crosses that boundary by hand.

The infrastructure data already exists and is maintained in the NetBox Labs platform. The problem is making that data available in the workflow where people actually need it. The NetBox Labs Jira Assets Integration is now generally available, and it puts that model into Jira Service Management Assets as native, linked, queryable objects that stay up to date. If your team uses the NetBox Labs platform and your service desk runs Jira Cloud with Assets, the lookup stops being your job.

What keeps a CMDB trustworthy

Storing a configuration record has never been the hard part. Keeping it current is. Without a maintained upstream feed a CMDB gets populated once and drifts from there, which is why Forrester found that over half of those surveyed do not trust their CMDB. That is a feed problem more than a tooling one.

Jira Assets is deliberately flexible and will model whatever you define, which means the object types, attributes, and references have to exist before a single record can move. Mapping one rich data model onto another is real work, and it has to be finished before anyone sees any value.

The schema builds and validates itself

The first run provisions the whole schema, all 28 object types with their attributes and their references, before any data moves. What used to be a modeling project becomes one command.

Every run after that rechecks the target schema before it writes, and an error stops the run rather than letting mismatched data through. A check-only mode lets you gate the run inside a pipeline you already have.

You control how far it reaches. Scope the sync to chosen object types, or to virtual machines carrying particular tags, and widen once the first layer is trusted. The schema ships and versions with the product, so keeping it current is our job rather than a build your team maintains.

Every device, rack, and IP, where the ticket already lives

The object types span core NetBox, virtualization, and the netbox-inventory and netbox-lifecycle plugins:

• Physical infrastructure. Devices, racks, sites, locations, and regions arrive as native records, and the relationships that matter provision as clickable Jira Assets references. Open a device on a ticket and get to its rack, its site, and its region without leaving Jira.
• Addressing and virtualization. IP addresses, interfaces, and virtual machines come across too, so the detail an approver needs is attached to the change rather than looked up during it.
• Lifecycle and procurement. Where you run the netbox-inventory and netbox-lifecycle plugins, contracts, renewal dates, end-of-life dates, purchases, deliveries, suppliers, and licenses sync alongside everything else, so renewal work happens next to the devices it covers.
• Your own fields. NetBox custom fields map into Jira Assets automatically as cf_-prefixed attributes, with no mapping file to maintain, so local naming conventions survive the sync.

These are native Jira Assets records, not imported text, so the Jira tooling you already run works against them: queries, reports, dashboards, and automation rules that key on site, rack, device type, or tenant.

The NetBox Labs platform stays authoritative, the service desk consumes

The sync runs one way, so change happens in the NetBox Labs platform where it is reviewed, and the service desk sees the result. It runs on a schedule you set, which means you decide when the Jira record refreshes.

After the first run, only changed objects are written. Objects match on netbox_id rather than on name, so renaming a device updates its record rather than creating a second one. Objects deleted in the NetBox Labs platform are removed from Jira Assets after a grace period you set, so the record does not accumulate hardware retired two years ago.

Teams can use the same authoritative NetBox Labs platform data with the service management platform they’ve standardized on. The NetBox Labs CMDB Integration for ServiceNow is certified on the ServiceNow Store, and Jira Assets now extends that same pattern to Jira Service Management. In either case, the infrastructure record stays authoritative in the NetBox Labs platform while the service desk gets the context it needs in the workflow.

What it looks like in practice

A schema build, taken over. A team starts modeling the Jira Assets schema, gets deep into attribute types and references, and finds the effort competing with everything else on the roadmap. The integration provisions the full schema, validates it before every run, and keeps it populated incrementally. The result is a usable Jira Assets model without weeks of manual schema design and ongoing maintenance.

Contract renewal from the service desk. Renewal dates live in a spreadsheet beside the ticket queue, maintained by whoever inherited it. The stakes are not only administrative. VulnCheck found that 42.5% of the network edge device vulnerabilities it cataloged as exploited in 2025 affected end-of-life or likely end-of-life devices. With contracts and end-of-life dates synced next to the devices they cover, a Jira query returns everything expiring inside ninety days, and an automation rule raises the renewal ticket. Teams can identify upcoming renewals and end-of-support risks from the same workflow instead of maintaining a separate tracking process.

A change request with its blast radius attached. The device on the ticket is a linked object. The approver clicks through to its rack, its site, and its region, and sees the addresses attached to it, all reflecting the current infrastructure record. Instead of sending the ticket back for manual lookups, the approver can review the change with the relevant infrastructure context already in Jira. The approval record also shows what was in scope at the time.

Across these workflows, the benefit is the same: Jira teams get current infrastructure context without making Jira the system of record. That means less manual lookup, less schema maintenance, and more opportunities to automate service workflows around the infrastructure relationships already maintained in the NetBox Labs platform.

Getting started

The NetBox Labs Jira Assets Integration is generally available today. You’ll need an ITSM integration entitlement from NetBox Labs and a Jira Cloud account with Assets enabled.

If you are already a NetBox Labs customer, reach out to your account executive or customer success manager. They will help you scope a first run to one group of object types, which is the low-risk way to start and easy to widen once the team trusts it.

Not a customer yet? Request a demo and we will walk you through the integration alongside the rest of the platform.