User documentation ยท Last updated 8 July 2026
Hardware Support Hub turns Jira into a serial-number-centric support tool: every issue can be tied to a physical unit, so you see a device's entire repair history the moment you open a ticket. This guide covers everything the app does and how to use it.
| Term | What it means |
|---|---|
| Unit | A physical device, identified by its serial number (and optional model). A unit accumulates a history of every issue linked to it. |
| Incident | A Jira issue linked to a unit. One unit can have many incidents over its life. |
| Symptom | A specific problem recorded on an incident, chosen from a taxonomy you control. One incident can hold several symptoms, each resolved independently. |
| Taxonomy | Your project's configurable list of symptom types, subtypes, and per-type data fields. |
| Unit status | A lifecycle label for a unit (e.g. Watch, RMA, Dead), configurable per project, with an optional shared note. |
Install the app from the Atlassian Marketplace onto your Jira Cloud site. No setup is required to start - the app ships with a default symptom taxonomy and a starter set of unit statuses. After installation you'll find:
The panel is where day-to-day support work happens.
Enter a serial number (and optionally a model) to link the issue to a unit.
Serials are normalized to uppercase and may contain letters, digits, and the
characters . _ - (up to 64 characters), so lookups always match
regardless of how the serial was typed. Once linked, the panel shows the
unit's full incident history across the project - you can see at a
glance that this is, say, the unit's fourth return.
Correcting a mistyped serial re-links the issue to the right unit and cleans up automatically: a unit left with no incidents (and no status flag or note) is removed rather than stranded.
Add one or more symptoms per incident. Each symptom has a type and, where configured, a subtype and required data fields - for example a "firmware update failed" symptom can require the firmware version. Required fields are enforced, so the detail you need is always captured.
Resolve each symptom independently, with its own resolution note - a single incident often has more than one problem with more than one outcome (the firmware issue fixed remotely, the noise complaint returned for repair). Resolved symptoms can be reopened if the problem recurs. Every symptom records who reported it and who resolved it, shown with the user's name and avatar, along with the timestamps.
From the panel you can set the unit's lifecycle status (e.g. Watch, RMA) and a shared note. The status and note are properties of the unit, so they appear on every incident tied to that serial - a warning that travels with the device.
A summary strip leads with the headline numbers for the project:
A sortable, paginated table of every tracked unit - serial, model, status, incident count, and last activity. Sort by most incidents, most recent activity, flagged-first, or serial. Click any serial to open its detail view.
Drills into one serial: every incident with its open/resolved symptom counts and symptom names, a per-unit CSV export, and a delete action. Deleting a unit unlinks it from its tickets (with a warning first) while preserving those tickets' symptom history - that history is incident data, not unit data.
Look up any single serial directly to jump to its history without scrolling the table.
The taxonomy editor on the project page lets you create symptom types, subtypes, and fields (text or number, required or optional). The app ships with a hardware-oriented starting set - Power, Firmware, Mechanical, Connectivity, and Sensor / readings - which you can rename, extend, or replace entirely to match your own product's failure modes. Ids are duplicate-safe, and destructive edits ask for confirmation.
The unit-status editor defines your lifecycle labels. Each status has a name, a lozenge colour, a "flagged" toggle (which drives the Fleet-health flagged count), and exactly one is marked as the default new units start in. The app ships with Active (default), Watch, Under test, RMA, Dead, and Decommissioned. Deleting a status moves any units on it to the default when you save, so no unit is ever stranded in an unknown state.
When you link a serial, the app writes it to an indexed issue property, so you can search across Jira with plain JQL:
hardwareSerial ~ "SN-2026*"
The hardwareSerial and hardwareModel properties can
also be used as conditions in Jira Automation rules. If your Jira site hasn't
finished indexing a newly linked serial, allow a short delay before it appears
in search results.
Two Copy CSV buttons produce a CSV. Neither downloads a file
- the CSV is shown as text on the page for you to select, copy, and paste into
a spreadsheet or save as a .csv file yourself.
The app is built entirely on Atlassian Forge and makes no calls outside Atlassian's infrastructure - your serial numbers, unit history, and symptom data never leave your Atlassian site, and are stored with data residency support via Forge's built-in storage. The only personal data stored is the Atlassian Account ID of the user who reported and who resolved each symptom; this is reported to Atlassian periodically and erased automatically if the associated account is closed. See the Privacy Policy and Security Policy for details.
The app requires an active licence. While unlicensed it runs in read-only mode - existing data stays visible, but changes are blocked until a Jira admin starts or renews the subscription.
To keep the app fast and predictable, the following limits apply:
| Item | Limit |
|---|---|
| Serial number length | 64 characters |
| Model length | 100 characters |
| Symptom types per project | 30 |
| Subtypes per type | 20 |
| Fields per type | 10 |
| Symptoms per incident | 30 |
| Incidents per unit | 500 |
| Unit statuses per project | 20 |
| Resolution / note length | 2000 characters |
The fleet dashboard and Units table scan up to several thousand units per project; the fleet CSV export, which reads every symptom, covers a smaller number of units per run. If a project's fleet is larger than the scan can cover in one pass, the app indicates that the view is truncated.
Confirm the app is installed and enabled for the site, and that you have permission to view the issue. The panel appears on standard Jira issues.
Search relies on Jira indexing the serial after it's linked. Give it a moment after linking, and confirm the serial was saved on the issue panel. Unit history still works through the app even before the index catches up.
No. Deleting a unit unlinks it from its tickets but preserves each ticket's symptom history.
If the app is unlicensed it is read-only. Ask your Jira admin to check the subscription in Atlassian Admin.
If the user's Atlassian account has been closed, its identity is removed from the record for privacy while the rest of the symptom (type, resolution, dates) is preserved.
Questions, bug reports, and feature requests are welcome at ccctools@proton.me. For security issues specifically, see the Security Policy.