Linking Equipment to Tickets

Linking equipment to tickets

A ticket can record which device it is about. "My monitor is flickering" arrives naming the monitor, with its make, model, serial number and warranty already attached — and the monitor, in turn, remembers every ticket ever raised against it.

Asked for in discussion #57.

---

The two halves

Linking — an analyst attaches equipment from the ticket, or the requester picks their own device when raising one in the portal.

History — every asset gains a Tickets tab listing what has been reported against it.

The second half is the one that pays for the first. Linking on its own is data entry: somebody does extra work and gets nothing back. The history is what turns three separate "my monitor is flickering" tickets into this monitor has failed three times, replace it.

On a ticket

Equipment lives in the Links bar at the top of the ticket, alongside problems, changes, related tickets and issue-tracker links — everything that answers "what else is this connected to". Each item is a pill marked 🖥️.

Open Link to… → Equipment and a picker appears that is already showing something useful before you type: the equipment assigned to the person who raised the ticket, under Assigned to the requester.

That is the answer most of the time, and it is one click. Start typing and the search widens to the whole estate under All equipment.

Hover a pill for its make, model, serial number and location; click it to open the asset; use the ✕ to unlink.

CMDB objects sit in the same bar, marked 🗄️, and are attached the same way. They are deliberately kept distinct rather than merged into one list, because they are different kinds of thing — a broken mouse is an asset and will never be a configuration item, and linking a configuration item is what feeds impact analysis. The only real overlap is a server, which can reasonably be both.

Searching by location is the important part

The picker searches hostname, manufacturer, model, serial number, asset tag — and location.

The location is not a nicety. Consider the case the feature was designed around: somebody from Finance reports that the TV in meeting room 3 has stopped working. They do not own that TV. Nobody does. And nobody involved — not the reporter, not the analyst — knows its hostname or serial number. What they know is where it is.

Without location in the search there is nothing useful to type, and shared equipment becomes effectively unlinkable.

⚠️ This only works if your assets have locations set. Locations are configured under Assets → Settings → Locations and set per asset. If your estate has no locations recorded, searching for a room name finds nothing — that is missing data, not a broken search.

In the self-service portal

When raising a ticket, a requester sees Which equipment is this about? listing the kit assigned to them.

They can only ever pick their own equipment. There is no search and no browsing — the list comes from what is assigned to them and nothing else is reachable, including by a hand-crafted request.

The field is hidden entirely for anyone with no equipment assigned, rather than shown empty.

Shared equipment is deliberately absent

The meeting room TV that motivated the location search cannot be picked by a requester, because nobody is assigned it.

That is a decision, not an oversight. The alternatives were each worse:

Option	Why not
Let requesters pick any unassigned asset	Solves a meeting-room problem by making every spare laptop in a cupboard browsable to every end user
Add a "shared" flag to assets	Precise, but somebody has to maintain it, and it asks end users to understand a distinction they should not have to

So the requester describes it in words, exactly as they do today, and the analyst attaches the asset when they pick the ticket up. Nothing is lost.

On an asset

The Tickets tab shows open tickets first, then everything that came before.

A long history is capped at the twenty most recent closed tickets, with the true total shown next to the heading, so a device that has been in service for years still opens quickly.

Tickets appear here only once somebody has linked the asset. Nothing is linked automatically, so the tab stays empty for assets nobody has attached to a ticket.

What happens to links

Event	Result
Ticket is merged into another	Links move to the surviving ticket; duplicates are collapsed
Ticket is deleted permanently	Links go with it
Asset is deleted	Links go with it; the tickets themselves are untouched
Same asset linked twice	Quietly ignored — the second link is a no-op, not an error

On a multi-company install, a ticket and an asset must belong to the same company to be linked, and that is checked when the link is made rather than assumed.

---

See also

• Assets — the module the equipment lives in
• Tickets — the reading pane this section sits in
• Self-Service Portal — where requesters pick their own device
• CMDB — configuration items are linked to tickets separately, and are not the same thing as assets
• 🛠️ Linking equipment — Developer Guide — the schema, the three gates, and where a new ticket-child table must be registered
• In-app guides: Tickets → Help → Working with tickets, and Assets → Help → Tickets on an asset