💡 How to show users which Assets are assigned to them?

[#1]

In many organizations, 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 do not 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.

And that gap results in:

• Repetitive support tickets

• Manual lookups by IT

• Delays in offboarding

• Friction during audits

• Confusion during renewals

• 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?

Should asset information be:

• Reactive (only visible during ticket creation)?

• Periodic (sent by email)?

• Or continuously available as self-service?

Solving this is not just about convenience.
It’s about operational efficiency and transparency.

---

🔹 Option 1: Automation + Email

You need to somehow obtain a list of users (ID and email addresses).

This typically requires using the “Send web request” action to retrieve users, followed by branching and running an AQL lookup per user via API - Get users from group [ATLASSIAN API] 

Then create a branch with {{webResponse.body.values}}

After that, perform a Lookup objects. Example AQL:

objectType = Laptops and Owner = {{user.accountid}}

And on a schedule, send the user a list of their assets by email, using {{user.emailAddress}}

Result:

Pros:
✔ Uses out-of-the-box automation
✔ Does not require an additional interface

Cons:

✖ Requires setting up a web request and working with API token/authorization
✖ Difficult to configure for multiple schemas. No single email with all objects.
✖ Static information
✖ No real-time updates
✖ Emails get lost
✖ No convenient filtering

This is a workable option but more of a temporary solution.

---

🔹 Option 2: Display assets in the JSM portal

Another approach is to provide the user with a self-service view directly in the JSM portal. One way to implement this is to build a custom portal view.

We recently implemented this approach in our app Assets Gadgets for Jira Dashboards & Reporting.

In the configuration, you can define schemas, object types, and the exact attributes that should be visible to users.

Using a controlled AQL query like:

Owner = currentUser()

This makes it possible to safely display only the objects assigned to the current user.

If you use links to objects, you can also use something like

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

Important:

• The user does not get access to the entire schema

• No ability to execute arbitrary AQL queries

• Filtering occurs at the application level

• The substitution currentUser() is used for the current user

This ensures transparency without violating the access model.

In our case, this is implemented through the JSM portal, with the addition of a "My Assets" section.

Supported:

• Multiple schemas

• Different AQL queries for different schemas

• Selection of specific attributes for display

The goal is not to "open everything," but to reduce support load and increase transparency.

This turns Assets from an internal IT database into a transparent self-service layer.

Pros:
✔ Quick and easy setup
✔ Ability to display data from different schemas and object types
✔ No webhooks or API tokens needed
✔ Real-time updates

---

🔹 Option 3: Embedding Assets in the request form

You can use Assets fields in the request creation form with dynamic AQL.

This is convenient if the asset is needed at the moment of ticket creation, but this approach does not provide the user with a general list of assigned objects.

---

🧩 Key question

Which approach to choose?

• Reactive — only at the moment of request creation?

• Periodic — via email?

• Or constant self-service access in the portal?

I'm curious how you solve this task in your projects. Share in the comments!

[Arkadiusz Wroblewski]

@Oleksii Melnyk _MOY Apps_ 

Love this write-up, you nailed the real problem: Assets is usually “perfectly tracked” and still invisible to the people it’s about, which then creates tickets for information you already have.

If I had to answer your “which approach is best” question:

For me, Option 2 (self-service in the portal) is the mature solution when the goal is transparency + ticket deflection. Email (Option 1) works as a quick bridge, but it’s fragile (tokens, user lists, multi-schema headaches) and it’s never real-time. Option 3 is great, but it’s reactive, it helps at request creation, not with “what do I currently have assigned”.

One thing I’d add as a best-practice note: whichever way you do it, the success factor isn’t the UI, it’s the ownership attribute being clean (Owner/Managed by/etc.). If that’s fed reliably from Entra/HR (or consistently maintained), self-service becomes gold. If ownership is messy, any approach just exposes messy data.

[Oleksii Melnyk _MOY Apps_]

@Arkadiusz Wroblewski totally agreed with you!

[Kevin Thibeault]

@Oleksii Melnyk _MOY Apps_ Can this portal be set up for the HR department to look up the assets assigned to a departing employee so that those items can be returned and verified?

[Oleksii Melnyk _MOY Apps_]

@Kevin Thibeault Hi!

Yes — this is definitely possible.

Depending on your current Assets structure, it may require some adjustment of attributes. But this is fully configurable and manageable.

One quick question — do your HR users currently have access to Jira (with licenses), or are they working only through the JSM portal?

That detail helps determine the cleanest configuration approach.

[Kevin Thibeault]

Thank you for the quick response. It is good to hear that this may be possible. Our HR users do not have access to Jira, and I would like to set this up for them in the portal.