Showing assigned Assets to users in JSM

Assets in JSM hold everything — laptops, licenses, contracts — but end users rarely see what's tied to their name. Three ways to close that gap, with the trade-offs of each.

Originally posted by us on the Atlassian Community App Central.

The transparency gap

In many organisations, Jira Service Management and Assets are used to maintain a structured inventory of:

• Laptops and mobile devices
• Software licenses
• Contracts
• Access credentials
• Subscriptions
• Other company-owned resources

From an IT perspective everything is properly tracked. From a user perspective — it's often a black box. End users typically don't know:

• Which exact device is registered under their name
• What licenses they currently hold
• When something expires
• Who is formally listed as the owner

This creates a gap between data availability and data transparency. The gap results in repetitive support tickets, manual lookups by IT, delays during offboarding, friction during audits, confusion at renewal time, and reduced trust in internal processes.

The core question: if Assets already contains structured, reliable data — why is it still hidden from the people it describes?

Option 1 — Automation + email

You can build this with native Jira automation:

1. Pull users (ID + email) via a Send web request action — for example, Get users from group.
2. Branch over {{webResponse.body.values}}.
3. For each user, run Lookup objects with AQL: objectType = Laptops AND Owner = {{user.accountid}}.
4. On a schedule, email the result to {{user.emailAddress}}.

Pros: uses out-of-the-box automation; no extra UI surface to maintain.

Cons: requires a web request with API token, hard to scale across multiple schemas, no single combined email, static information, no real-time updates, emails get lost, no filtering on the receiver's side.

Workable as a short-term workaround. Not great as a long-term answer.

Option 2 — Show Assets directly in the JSM portal

A self-service view in the portal removes the email loop entirely. We recently implemented this in our Assets Gadgets for Jira (Dashboards & Reporting).

In configuration you define which schemas, object types, and attributes are visible to users. The filter is a controlled AQL query:

Owner = currentUser()

If the relevant attribute is a link to another object, you can dive one level deeper:

"Owner"."Atlassian Account ID" = currentUser()

What this guarantees:

• Users don't get access to the entire schema
• Users cannot run arbitrary AQL queries
• Filtering happens at the application level — currentUser() is substituted server-side
• Transparency without breaking the access model

In our deployment the gadget renders a "My Assets" section inside the JSM portal. It supports multiple schemas, different AQL filters per schema, and explicit attribute selection so only the relevant columns appear.

Pros: quick setup, multiple schemas + object types, no webhooks or API tokens, real-time updates.

The goal isn't "open everything" — it's to reduce support load and turn Assets from an internal IT database into a transparent self-service layer.

Option 3 — Embed Assets in the request form

You can drop an Assets field with dynamic AQL into the request creation form itself. Useful when the user needs to pick an asset at the moment of ticket creation — e.g., "report a broken laptop, pick yours from the list."

It does not give a general overview of assigned objects, so this is a complement to options 1 or 2, not a replacement.

Which to pick

Three honest answers depending on your context:

• Reactive — embed in the request form (Option 3) when the asset only matters during ticket creation.
• Periodic — automation + email (Option 1) when you have no portal customisation budget.
• Always available — render in the portal (Option 2) when you want zero support tickets for "what's assigned to me?"

How are you solving this for your organisation? We'd love to hear — drop us a note via Support.