Bring Jira Assets into your Jira boards with BetterBoard

[#1]

I work on BetterBoard at Released, so this post uses BetterBoard as the example.

On an incident board, a ticket reporting VPN access problems can look much like any other access request. The link to the production VPN service sits inside the issue’s Assets field, along with the status and ownership details needed for triage. An agent has to leave the board to inspect

BetterBoard puts the linked Asset on the card as a chip. Hovering it opens a view of the asset with its avatar and the attributes selected for the field. For a service, that could include environment, service tier, status and owner. For a laptop, it could include model, serial number, warranty status and assignee.

The card does not need every attribute from the asset record. For incident and change work, a short set of fields that affects triage is more useful than a complete asset dump.

Filter the board by the asset behind the work

The asset chip helps when reviewing a card. Filters help when the team needs a board for a particular situation.

A service desk can filter to issues linked to the VPN service during an incident. A change manager can filter to work connected to production assets. A fulfilment team can focus on requests for one laptop model or devices assigned to a particular office.

BetterBoard exposes the Asset field, an operator and a value in the filter controls. A user can choose an individual asset or select an attribute such as environment, owner or lifecycle status. The filter is configured without writing JQL or AQL.

A team can keep separate boards for its normal incident queue, tier-one services and an active service investigation. Each board reads the same Jira work items but applies a different filter and card setup.

Highlight matching work without removing the queue

A filter hides the cards that do not match. That is useful when the team needs a narrow view, but a change review or stand-up often needs the full queue.

Card colours retain the complete board and highlight the cards that match an Asset rule.

An incident board might colour cards linked to a tier-one service red and cards linked to other production services amber. A device-fulfilment board might colour requests for assets in repair. A change board could call out work affecting a service that is already degraded.

The rules use the same Asset and attribute information as filters. The difference is whether the team wants to isolate the matching work or see it in context with everything else.

Use the same approach outside IT service management

A vehicle-testing team can create a Jira issue for every fault found during testing and link the issue to the relevant test vehicle in Jira Assets. The vehicle record may include its model, build, programme and fitted components.

A fault board often begins as a list of symptoms and workflow states. Reviewers need the test vehicle and model context to see whether the faults appear limited to one prototype or recur across a fleet.

Showing the vehicle on each card gives the reviewer that context without opening every issue. A filter can isolate faults linked to one vehicle or model. A colour rule can identify faults on pre-production prototypes or vehicles fitted with a component under investigation.

This works because the information already exists in Jira Assets. BetterBoard makes it available in the board views used for triage, review and planning.

Add a screenshot here showing an asset chip, an Asset-attribute filter and matching card colours on the same board. Remove or obscure real customer names, service names and asset identifiers before publishing.

BetterBoard is available on the Atlassian Marketplace.

Which Asset attributes do you need during incident triage, change review or testing?