Populating Atlassian Jira Custom Fields with your Lansweeper Assets Schema Data

Pro Tips #67

There is a good chance that if you are reading this you have installed the Lansweeper Jira Service Management Assets integration app and watched your asset schema quickly populate thousand of devices, software titles, and their configurations. If you haven’t already be sure and Take a moment to celebrate, as your Atlassian Jira Service Management CMDB just leveled up! Now that this is done you might be asking yourself “now what?” and that’s what we’ll be discussing in this blog post.

you can quickly and precisely retrieve exactly the assets you need. Whether limiting choices to a particular asset types with a specific status, AQL is flexible enough for both simple scenarios and complex filtering logic.

When setting up Assets custom fields, you’ll encounter two distinct but powerful configuration options: “Filter Scope” and “Filter Issue Scope.” At first glance, they might seem interchangeable, but each serves a unique purpose. Filter Scope sets the baseline for which objects are available in a field. For instance, you might limit the field to only windows devices. Filter Issue Scope, however, dynamically filters asset objects based on details already present in the Jira issue, like the reporter’s identity or selections made in other fields. Combining these two filters enables incredibly contextual, personalized experiences for both agents and end-users.

Query

ObjectType = "Windows" AND State = "Active"

The first critical step is bringing all of your lansweeper Asset Schema data into Jira’s everyday operations. And to do this we will start by populating Jira custom fields using Assets Query Language (AQL).

Why is it essential to populate custom fields with your asset data? The real power of integrating Lansweeper and JSM Assets isn’t just having the data, it’s making that data immediately available to agents, end users, and reporting dashboards. When configured correctly, custom fields can automatically display critical asset details or as we call them in Jira Service Management Assets “attributes”. Common attributes you might be used to working with would be a device’s model, warranty status, or assigned owner, we want this data to be available within Jira issues and forms. The result? Agents have instant context, significantly reducing resolution times. Requesters can easily choose from accurate asset lists rather than typing free-text details, eliminating guesswork and ensuring cleaner data entry. If this isn’t enough think of the “kudos” you’ll receive when leadership gains access to accurate reporting, dramatically improving visibility and compliance readiness.

So, how do we accomplish this? Meet your new best friend: Assets Query Language, or AQL. Think of AQL as a purpose-built query language specifically for Jira’s asset management. Similar in spirit to JQL, AQL allows you to filter your Assets schema dynamically. With straightforward queries like:

Here’s a practical example. Let’s say you want to create a custom field named “Impacted Asset,” showing only active laptops, desktops, or servers assigned directly to the reporter. To achieve this, you first define your Filter Scope with a query:

[ObjectType IN (“Windows”, “Apple Mac”, “Linux”) AND State = “Active”]

Then, you refine the selection further by adding a Filter Issue Scope that ties the field directly to the reporter:

[User.JiraUser == ${reporter}]

The moment a user opens a ticket, Jira uses these AQL conditions to dynamically return a concise, relevant list of assets. With just a few lines of configuration, you’ve significantly boosted both accuracy and efficiency.

Of course, complex implementations of Jira Service Management require thoughtful best practices. Keep your AQL queries lean and clear to ensure optimal performance. Always plan for graceful fallbacks. If a query unexpectedly returns no results, provide clear instructions in the field description for users. Maintain consistency in your naming conventions to help administrators quickly understand the logic behind each custom field. Regularly documenting your AQL queries in a shared knowledge base or Confluence page makes troubleshooting and future modifications straightforward, saving your team from unnecessary headaches down the road.

At this point, you’ve taken your first big step toward unlocking additional value of your Lansweeper|JSM integration. Your assets are no longer just a data repository, they’re active participants in every incident, request, change, or problem your teams handle. This foundation sets the stage for deeper integrations and automations, enabling smarter workflows, and better reporting.

Looking ahead, we’ve got an entire series planned to help you leverage even more advanced capabilities. In our next installment, we’ll explore how to automatically enrich Jira Work Items with asset data, eliminating manual steps and ensuring consistent information availability. Future blogs and companion videos will guide you through advanced features like surfacing vulnerabilities directly within Jira, streamlining self service options on your portal, automating CMDB hygiene tasks, and implementing proactive alerting with Jira Serivice Management’s Team Operations features.

Welcome to your integrated asset management future….Let’s make every Jira ticket count!