Looking for best practices using Assets

[Shawn_Giese]

Hi, looking to manage virtual things like contracts, exceptions with the assets. Ideally, any service ticket for a team would show all the teams assets (contracts / exceptions). 

I had thought that we would be wiring up a window of sorts to the asset data but it looks like we are adding asset ids into each ticket. Is there any way to just show links to related assets instead of actually embedding the selected asset into a selected ticket? 

So we made:

* asset object for all team names

* exception object with team names linked to previous object

Then a custom field to display exception objects where we want

Then automations to:
* update the team names if a team name is not already on the list

* populate the custom field with the exception object, filtered by team name in the ticket.

Hard to get the filtering right as the AQL filters on AQL based custom objects but the global filter seems to work.

Not sure about reporting on this data... maybe there are some guides for reporting on assets.

The custom field shows an "add exception" type actin button but it just adds from existing assets. Would be cool if that could either be a "create exception" button or simply not shown, all exception objects are already filtered.

Seems like it will be challenging to keep in sync without constant automation checks (why we would like to simply show an passthrough AQL query in tickets that is always up to date instead of assigning each individual asset exception object to each of the teams tickets.)

Assets are new to us... any best practices or suggestions are welcome.

[Arkadiusz Wroblewski]

Hello @Shawn_Giese 

I’d avoid automatically bulk-adding every matching Exception to a ticket. Assets fields store specific references, so this will quickly clutter your issues and risk hitting the 20-object limit per field.🙃

You can store the Team object on the ticket and link your Contracts and*Exceptions to that Team within Assets.

Agents can use the object graph for context, and you'll only need to attach a specific Exception if it's directly required for issue reporting.

For your field filtering, your AQL seems right for me, just ensure you use the custom field ID instead of the name: `objectType = "Exception" AND Team = ${customfield_xxxxx.label}`.

Best,

Arkadiusz🤠

[Shawn_Giese]

Thank you.

[garrett_lessard]

Hi @Shawn_Giese 

Displaying Assets as a live, related-data panel is a very common requirement in JSM. You will want to keep in mind that Jira's native Assets object field is inherently a reference field. It is designed to store specific object IDs directly on the issue, which is why you are seeing that "Add exception” and having to rely on automation to keep it synchronized.

Here’s some ways to handle this:

The ideal model: store one stable reference

Instead of copying a bunch of exception objects onto every single ticket, store only the Team (or another stable key) on the issue. You can then pull the related assets and exceptions dynamically from that single reference.

Set up your Assets schema so the Team object sits at the center. Your Exception and Contract objects should then have an attribute that points back to that Team. On the Jira issue itself, you only need a single Assets object field for the Team. The issue stays clean, and all the complex mapping lives inside your Assets schema.

How to show related assets without saving them to the ticket

If your agents just need to see this data while working on a ticket, you have a few options:

Use the native Assets panel: Agents can simply click into the Team object directly from the issue view. This opens a side panel showing all inbound and outbound references, like exceptions and contracts, just one click away.
Use a Marketplace issue panel: If you absolutely need an inline table on the issue view that changes dynamically based on the selected Team, look for an app that renders dynamic issue panels or scripted fields. These apps run an AQL query on the fly using the issue context without saving those results back into a field.
Make the field read-only: If you absolutely must use an Exceptions field for JQL reporting, lock it down. Use your field configuration or request type layouts to make it read-only for agents and hidden from customers, then let automation populate it in the background.
Why this feels painful

Right now, you are duplicating relationship data by copying exceptions from your schema onto individual issues. This is usually brittle because AQL inside Jira automation can easily break when you start mixing object references with global filters.

Unless you have a strict requirement to run JQL queries like "find all issues where exception X applies," you do not need to store exceptions on the ticket. Keep the Team field as your single source of truth and use a live display method instead.

Managing the "Add exception" button

The "Add" button appears because the field expects a user to manually select an object. If you want to get rid of it, your best bet is to make the field read-only on your agent views. If you actually need agents to create new exceptions during a request, you should use a portal form / JSM form to capture exception details and then automation creates the Exception object (works, but it’s a workflow). You can also use a Marketplace app that provides "create Assets object from issue" actions.

Let me know if this helped!

Garrett Lessard Appfire Expert Services

[Shawn_Giese]

Thank you for the guidance.

The reason we were thinking of storing the exception objects in the ticket was for compliance purposes... say a year down the road, we reviewed a ticket... we would want to know which exceptions were active at the time of the ticket.