How to use a Jira project as a light-weight CMDB with cascading fields in JSM

[#1]

Full disclosure: I'm the Product Marketing Manager for Elements Connect at Elements Apps. Happy to answer questions on fit in the comments, including the cases where this isn't the right tool.

---

When a customer raises an incident in Jira Service Management, one of the most common requests portal admins get is deceptively simple: "Can the customer just pick their own laptop or phone from a dropdown, instead of typing a serial number nobody remembers?" To do that well, the form has to read from an inventory that already exists somewhere and in many organizations that inventory is already a Jira project: one issue per asset, with custom fields for the attributes that matter.

This article shows how to use an existing Jira project as a light-weight CMDB (Configuration Management Database) and expose it on the native JSM request form as three cascading fields: asset type → asset name → status. The twist worth reading for: the project holding your assets can live in your same Jira Cloud site, or in a completely separate one you have API access to, the setup is the same either way.

By the end you'll know how to build a guided asset picker on a JSM portal that reads live data from a Jira project, wherever it lives, and that shows each customer only the assets that belong to them.

---

The problem: the data is in one place, the need to use it is in another

Picture a large organization where the central IT team owns the asset inventory, their Jira site, their governance, their data hygiene. Meanwhile, individual business units run their own Jira Cloud sites and service desks, often because they adopted Jira independently over the years.

When someone in a business unit raises "my laptop won't boot", that desk would love the customer to pick the exact device from a dropdown, but the business unit has no desire, and no business, duplicating and maintaining IT's inventory. Copy it once and it drifts within a week.

That's the trap: the data lives in one place, the need to use it lives in another, and neither migrating nor duplicating is acceptable. The same shape shows up for a managed service provider reading each client's inventory from the client's own Jira site, and for any team that just wants to display data from another Jira project on a request form without copying it.

What we need is a way to look up data in another Jira issue, potentially in another project or site, and surface it live on the JSM portal, with no duplication.

---

Two terms, quickly

Because they get overloaded:

• Connected field: a native Jira/JSM custom field (JQL-searchable) whose options are populated by a query instead of a static list you maintain by hand. Here, the source happens to be another Jira project.

• Cascading: each field's query depends on the value chosen in the previous field. Pick Laptop in the first field and the second only offers laptops. That's dependency-driven data retrieval, different from simple conditional show/hide logic, which just reveals or hides a field without changing what data it pulls.

---

What we're building

Three cascading connected custom fields on a JSM request type:

• Asset type: a single-select list showing every asset type in the inventory project (e.g. Laptop, Phone).

• Asset name: a single-select list showing the assets that match the selected type and belong to the logged-in customer.

• Asset status: a read-only field that automatically displays the current status of the selected asset.

Each field feeds off the one before it (that's the cascade), and all three read from the same Jira-to-Jira data source.

The walkthrough keeps the inventory project and the service desk on one site for readability. Every step is identical when the inventory lives on a separate Jira Cloud site: you simply point the data source at that other site.

---

Prerequisites

• A Jira project to hold your assets, this tutorial calls it CMDB. It can be in the same Jira Cloud site as your service desk, or another one you have REST API access to.

• Elements Connect installed on the site that hosts your JSM project.

---

Step 1 - Turn a Jira project into your asset inventory

We'll model two things as issues: the asset types and the assets themselves.

1. In the CMDB project, go to Project settings → Work items → Types → (Actions) Edit work types.

2. Add a new issue type Asset type, add it to the scheme, and save.

3. Repeat for a second issue type, Asset.

Now create the records:

• Create issues of type Asset type for each category - e.g. Laptop and Phone.

• Create issues of type Asset for each physical item - e.g. Lenovo ThinkPad X260, iPhone 7, MacBook Air.

Then link each asset to its asset type with an issue link (open an Asset type issue and use Link issue), creating a parent-child relationship: asset type = parent, asset = child. This link is what makes the cascade possible later.

Finally, set the Assignee of each asset to the customer who owns it - that's what lets the portal show a customer only their devices.

At this point your CMDB project is a small but real inventory: categorized, linked, and owned.

---

Step 2 - Create the Jira-to-Jira data source in Elements Connect

Open Apps → Elements Connect from Jira, and create a REST API data source pointing to the Jira REST API, authenticated with basic auth. This is the piece that lets Elements Connect read your inventory:

• If the CMDB project is in the same Jira Cloud site, point the data source at that site.

• If it's in a different Jira Cloud site, point it there instead - the mechanism is identical, you just target the other site's REST API.

That's the whole idea of a Jira-to-Jira data source: Jira reading Jira over the standard REST API, regardless of which site the data lives on.

---

Step 3 - Create the three cascading connected fields

All three read from the Jira data source you created in Step 2. Each connected field is set up the same way in the Elements Connect field editor: you choose a field type, point it at your Jira data source, tell it which issues to fetch, and decide how each option is displayed. Here's what each of the three fields does, the exact queries are in the documentation, and you'll adapt them to your own project and field IDs.

3a. Asset type

Create a connected custom field named Asset type, of type Select list (single choice), using your Jira data source.

• What it fetches - every issue of type Asset type in the CMDB project (in our example, Laptop and Phone).

• What the customer sees - a dropdown of asset categories, each shown by its issue summary.

This is a plain lookup: no dependency yet, it simply lists the categories that exist in your inventory.

3b. Asset name

Create a second connected custom field named Asset name, again Select list (single choice) on the Jira data source.

• What it fetches - the assets that are linked to the asset type chosen in the previous field, filtered to those where the assignee is the logged-in customer.

• What the customer sees - only the devices of the selected type that actually belong to them.

This is where the cascade happens: the query references the value selected in the Asset type field, so the options here change depending on that first choice. Scoping to the current user is what turns a full inventory into a personal device list. The dependencies between connected fields guide shows exactly how to reference a parent field in the query.

3c. Asset status

Create a third connected custom field named Asset status, of type Read-only.

• What it fetches - the current status of the asset chosen in the Asset name field.

• What the customer sees - a non-editable field that fills in automatically once they pick their device (e.g. In use, In stock).

No input needed from the customer - it's there to give both the customer and the agent instant context on the selected asset.

The result is a chain: Asset type constrains Asset name, and Asset name drives Asset status, with no manual list maintenance anywhere. For the exact query syntax used at each step, see the Elements Connect query guide.

---

Step 4 - Add the fields to your JSM request form

In Elements Connect, go to Connected fields, and for each of the three fields use Actions → Add field to Portal. Choose your JSM project and the request type, then drag and drop the three connected fields onto the request form.

That's it. On the native portal, a customer raising an incident now:

1. picks an asset type,

2. sees only the assets of that type that belong to them,

3. and watches the status of their chosen asset fill in automatically.

---

The result

No serial numbers typed from memory, no free-text guessing. The customer gets a guided, three-step asset picker, and the agent receives a request already tied to a known device and its current status - pulled live from a Jira project that may be sitting on an entirely different Jira Cloud site, owned by an entirely different team.

---

FAQ

Does the asset inventory have to be in the same Jira site as my service desk? No. Because Elements Connect reads Jira through its REST API, the inventory project can be in your same Jira Cloud site or in a separate Jira Cloud site you have API access to. The configuration is the same; only the data source target changes.

How is this different from Atlassian Assets? Assets is Atlassian's purpose-built CMDB, available on JSM Premium and Enterprise, with its own object model. The pattern here is lighter: it reads asset records that already exist as issues in a Jira project, which suits teams who don't have Assets or who don't want to migrate an existing Jira project into it. If Assets fits your needs, use it.

Do the cascading fields work inside JSM Forms? No, the connected custom fields created in Elements Connect are currently only available on JSM project and portals, but not on JSM Forms.

Are these real Jira custom fields I can search on? Yes. Connected custom fields are standard Jira custom fields, so they're JQL-searchable and usable in filters and dashboards like any other field.

---

Final thoughts

Giving JSM customers a clean way to pick their own assets when they raise a request is a small change with an outsized payoff: fewer wrong serial numbers, faster triage, and agents who receive a ticket already tied to a known device.

Jira's native options can get you part of the way - Assets is excellent when you're on the right plan and it's already your CMDB, and a plain custom field works when your inventory is tiny and static. But they fall short in the situation many admins actually face: the asset data already lives in a Jira project, often owned by another team on another Jira Cloud site, and neither migrating nor duplicating it is realistic. Connecting Jira to itself keeps one source of truth, maintained by the team whose job it is, consumed live by the desks that need it, with no drift.