Zoomed Image
USA
800 691 9120
UK
01225 704844

JIRA AI Asset Matching

xAssets Configuration Guide
Integration to Specific Applications

JIRA AI Asset Matching

The JIRA AI Asset Matching feature automatically identifies xAssets assets related to a JIRA issue by analysing the issue text using artificial intelligence. When a JIRA ticket is created or viewed, the AI scans the summary and description for identifying information — computer names, IP addresses, usernames, and the reporter's name — and matches these against the asset database. This page explains how the AI matching works, how to fine-tune it, and what happens when no match is found.

Prerequisites

  • The JIRA integration must be installed and configured. See JIRA Asset Panel Integration for the full setup process.
  • Assets must exist in xAssets with identifying data (computer names, IP addresses, custodian names) populated — typically through network discovery.

How AI Matching Works

When a JIRA issue is displayed, the xAssets integration performs the following steps:

  1. Text extraction — the AI reads the issue summary, description, and reporter name.
  2. Entity identification — the AI identifies potential asset identifiers within the text:
    • Computer names (e.g., "LAPTOP-JSmith01", "SRV-DB-PROD-03")
    • IP addresses (e.g., "192.168.1.100", "10.0.0.50")
    • Usernames and email addresses
    • The name of the issue reporter
  3. Asset lookup — each identified entity is matched against the xAssets database. Computer names are matched against the Computer Name field, IP addresses against the IP Address field, and usernames against the Custodian field.
  4. Priority scoring — each matched asset receives a priority score based on the strength of the match. Exact matches score higher than partial matches. Assets from categories listed in the MATCHINCIDENTCATEGORIES setting receive a score boost.
  5. Results presentation — matched assets are displayed in the JIRA issue's Assets custom field, ranked by priority score.

Match Lifecycle

The AI match goes through two phases:

Dynamic Phase (Before Save)

Before a user saves the match, the asset list is recalculated each time the JIRA issue is viewed. This means:

  • The match list may change if the issue text is edited
  • Different users viewing the same issue see the same dynamically-generated list
  • No data is persisted in xAssets at this stage

Saved Phase (After Save)

When a user clicks the Assets field and saves the match (with or without modifications), the match becomes permanent:

  • The saved asset list is stored and no longer recalculated
  • The AI matching stops for that issue
  • Users can still modify the saved list manually

Fine-Tuning the Matching

The AI matching behaviour is controlled by several settings (SpecialOptions) in Admin > Settings. Full details of each setting are documented in JIRA Asset Panel Integration. A summary of the key tuning options:

Adjusting Match Sensitivity

Setting Effect
AssetMatchingPriorityCap Controls the minimum score for a match to be shown. Increase the value to show only strong matches; decrease it to show more results including weaker matches. Default: 100.
MATCHINCIDENTSWITHAI Set to false to disable AI text scanning entirely. Only the reporter name will be used for matching.

Routing by Issue Type or Project

Use the AssetMatchingQuerySelection setting to route different types of issues to different matching queries. For example, you might want hardware issues to match against a "Hardware Assets" query and software issues to match against a "Licensed Software" query.

To configure routing:

  1. Set AssetMatchingQuerySelection to the field you want to route on (e.g., issuetype).
  2. Create additional settings with the naming pattern AssetMatchingQuery_issuetype_<value> for each issue type that needs a different query.
  3. Create corresponding AssetMatchingPriorityCap_issuetype_<value> settings if you want different thresholds per type.

See JIRA Asset Panel Integration for the full list of routing fields and examples.

Choosing the Matching Query

The AssetMatchingQuery setting specifies which xAssets query is used for matching. The default is "All Assets". You can change this to a more focused query to improve match relevance:

  • A query limited to IT assets (excluding furniture, vehicles, etc.) will produce fewer false positives for IT service desk issues.
  • A query that includes additional fields (e.g., serial number, MAC address) may improve matching if those identifiers appear in JIRA issue text.

What Happens When No Match Is Found

When the AI cannot find any matching assets:

  1. The Assets field in JIRA displays "No matching assets found" (or remains empty).
  2. The user can click the Assets field to perform a manual search within xAssets.
  3. The manual search allows text-based searching across all asset fields.
  4. Once the user selects assets manually and saves, the saved list is preserved for that issue.

Common reasons for no match:

Reason Resolution
The issue text does not contain identifiable asset information Users should include computer names or asset tags in issue descriptions
The asset has not been discovered yet Run a discovery scan to populate computer names and IP addresses
The matching query excludes the relevant assets Adjust the AssetMatchingQuery setting to use a broader query
The priority cap is too high Lower the AssetMatchingPriorityCap value to allow weaker matches

Tips

Tip: Encourage users to include the computer name or asset tag in JIRA issue descriptions. This significantly improves the AI matching accuracy.

Tip: Start with the default settings and monitor the matching results on real issues before fine-tuning. The default configuration works well for most environments.

Tip: If the AI is matching too many irrelevant assets, increase the AssetMatchingPriorityCap value. If it is missing valid matches, decrease it.

Warning: Changing the AssetMatchingQuery setting affects all future AI matches across all JIRA projects (unless overridden by AssetMatchingQuerySelection routing). Test changes on a small number of issues before deploying broadly.