Linking Tickets

Linking tickets to things

A ticket rarely lives in isolation. FreeITSM lets you connect a ticket to the other records it relates to — a problem, a change, another ticket, or a CMDB object — so the whole picture is visible from the reading pane, and from the other record's side too.

It all lives in one place: a purple Links section in the ticket's reading pane.

The Links section

Open a ticket and the reading pane shows a Links strip listing everything the ticket is connected to, as pills:

• ⚠ Problems — click to open in Problem Management
• 🔁 Changes — click to open in Change Management
• 🔗 Tickets — other tickets, prefixed with the relationship (Parent / Child / Duplicate of / Related); click to jump to them in the inbox

Each pill has an ✕ to unlink. A single Link to… button opens a small chooser — Problem, Change or Ticket — and then the matching searchable picker.

You can also start a link from the right-click menu on any ticket in the list (Link to problem…, Link to change…, Link to ticket…). The right-click actions target whichever ticket you clicked, even if a different one is open in the reading pane.

On a phone the Links section is tucked into a single Links sheet reachable from the reading pane, so it doesn't crowd the small screen.

Linking to a problem

The incident↔problem link works from either side (see Problem Management):

• From the ticket — pick Problem from the Link to… menu (or Link to problem… on the right-click menu). A searchable picker lists the company's open problems — click one to link, or Create a new problem from this incident in one step.
• From the problem — the problem detail page lists its linked incidents and has its own Link incident action.

Linking to a change

Connect the change that will implement or fix the work (see Change Management):

• From the ticket — pick Change from the Link to… menu (or Link to change… on the right-click menu), then search the change.
• From the change — the change detail page has a Linked incidents section and picker; linking/unlinking from either side writes to the change's activity log.

Linking tickets to each other

Pick Ticket from the Link to… menu, choose a relationship, then search the target:

Relationship	Meaning
Related to	Symmetric — the two tickets are connected, no hierarchy
Duplicate of	This ticket is a duplicate of another (the master)
Parent of / Child of	Hierarchy — a parent with one or more children

• Directional links read correctly from both ends — a Parent of TKT-123 on one ticket shows as Child of TKT-456 on the other.
• Cardinality: a ticket has at most one parent (a parent can have many children) and can be a duplicate of at most one master. Self-links and parent/child loops are rejected.
• Informational (v1): links display and are audited on both tickets, but they don't change ticket state automatically — behaviours like auto-closing a duplicate or cascading a parent close are a planned, Workflows-driven phase.

Linking to a CMDB object

Separately from the Links section, the reading pane has an Affected CMDB Objects area (between the email thread and the notes) — type to search across every CMDB object, click to link, ✕ to unlink. Each linked object shows as a card with its class + parent context. See CMDB for the reverse view (the object's Activity panel).

Multi-company installs

On a multi-company install, ticket↔ticket, ticket↔problem and ticket↔change links are same-company only: the picker is scoped to the source ticket's company, and a cross-company link is rejected. This is enforced server-side, not just hidden — see Isolation. On a single-company install it's automatic and invisible.

Where it's stored

Link	Table
Ticket ↔ ticket	ticket_links (source_ticket_id, target_ticket_id, relation_type ∈ related/duplicate/parent)
Ticket ↔ problem	problem_tickets
Ticket ↔ change	change_tickets
Ticket ↔ CMDB object	CMDB link table (see CMDB)

Every link/unlink between tickets is written to both tickets' activity logs. Run System → Database Verify after upgrading so any new link tables/columns are created.