Asset Management in Jira: Connecting projects with Atlassian Assets

[#1]

Hello again!

As now it's possible to have Asset fields at a Space level in Jira (projects) with Projectrak, teams can now connect them with objects they already manage in Assets, such as apps, services, clientes, suppliers, contracts, equipements, locations, and any other need. 

This means that if you have useful information about your projects already available in Assets, you shouldn't need to maintain it again somewhere else just to use it in your portfolio.

As part of the Deiser Apps (part of Devoteam) team, this is a very cool released feature, hence, I wanted to share how it's possible to bring Assets data into your project portfolio with Projectrak for Jira.

How does the Asset field work?

When creating an Asset field in Projectrak, previous there should be created the structure in Atlassian Assets, then, create the field name and description, establish permissions, and then run an AQL to determine which assets will be included and selected in the different Projectrak project portfolio views.

For example, imagine you work in a banking organization and your team has a core system called "Retail Banking Platform" registered in Atlassian Assets.

At the same time, you have several Jira Spaces (projects) managed with Projectrak for Jira, and some of them involve changes to that platform (like performance improvements or new digital banking features).

Using the new Asset fields in Projectrak, you can add a field like "Affected banking system"to your Projectrak project data and connect those projects directly with the "Retail Banking Platform" object from Assets. 

That relationship can become part of the information you see and manage from your project portfolio. 

So, instead of having plain project information in one place and the banking system in another, you can bring both together when reviewing your projects, as it follows:

You can customize Projectrak's Assets Field to fit your business needs:

Depending on how your organization uses Assets, you could connect projects with:

• Business services to understand which projects from different areas are changing
• Infrastructure or equipment to identify projects related to technical changes
• Clients or Accounts to see which projects belong to each customer.
• Suppliers to understand which projects depend on the same third party
• Contracts or cost centers to add more financial context to the portfolio.
• Critical Assets to identify projects affecting higher-risk areas of the company.

This means that Projectrak allows you to keep describing and organizing your projects in different convenient portfolio views, while Assets provides additional context around it.

As project portfolios need more context to allows them to be run more smoothly, the PMO stakeholders have now another way to understand the whole context surrounding their work.bb

If you're already using Atlassian Assets in Jira, I'd be curious to know: What type of Assets objects would be most useful for you to connect with your projects?

[Anwesha Pan]

Hi @Huwen Arnone _Deiser_Devoteam_, 👋🏻

This is a really practical feature highlight — thanks for walking through it so clearly.

The pain of maintaining the same information in multiple places is something nearly every PMO team deals with, and it only gets worse as portfolios grow. Being able to pull in Assets objects (services, contracts, systems) directly into the project portfolio view feels like a natural connection that should have always existed.

Quick question: for teams with complex Asset schemas, how does performance hold up when running broader AQL queries across large object sets? Would love to hear how others are scoping their queries to keep things responsive.

Great write-up — looking forward to seeing how this evolves!

[Marcelo Montaño Sánchez]

Hi @Huwen Arnone _Deiser_Devoteam_ 

Great!

I think it's a very good alternative to having to fill in references to Assets with Text fields.

[Huwen Arnone _Deiser_Devoteam_]

I'm glad you think it's a practical feature @Anwesha Pan

This feature was designed for organization where assets has grown into a quite large and complex structure.

And by answering your question directly, the Asset Field uses the AQL configured for that particular Project field, so keeping the query focused on the object of interest is the recommended approach. For example, limiting it by schema, object, or specific attributes rather exposing it to a large set of objects.

In the end, it depends on the use case. You know, each instance is a new world. I wouldn't like to give you a generic answer just because of that. Also because it depends on the structure built in Atlassian Assets and as I mentioned, the AQL used.

If you have a particular use case, we'll be delighted to talking to you about it and finding ways to adapt it better to your needs. You can book short meeting at this calendar.

Thank youuuu!! ))

[Huwen Arnone _Deiser_Devoteam_]

@Marcelo Montaño Sánchez!! Thank you very much for your kind comment. Indeed, we think the same as you. We discover the need among our customer and decided to implement it.

This feature makes life easier )) Instead of manually adding an Atlassian Asset reference, depending on the use case need (and the AQL), it's better just to natively allow to select the actual Asset object and make that relationship visible and part of the project portfolio data.

I will share this feedback with the team! Thank youuu!! ))

[Anwesha Pan]

That's really nice of you explaining it in detail @Huwen Arnone _Deiser_Devoteam_ :) Looking forward to use it in our org.