Skip to main content

Ticket Links, Comments, and Hierarchy

Execution work becomes easier to trust when related context is visible in one place. Use ticket comments for discussion, activity for audit history, links for relationships, and hierarchy for work that belongs under a larger outcome.

Comments​

Comments capture human context that does not belong in the ticket title or structured fields. Use comments for decisions made during execution, handoff notes, customer updates, and explanations for important status changes.

Good comments answer one of these questions:

  • What changed?
  • Why did it change?
  • Who needs to know?
  • What should happen next?
  • Which source or conversation explains this work?

Comment bodies are required. A comment can be edited or deleted by its author. When a comment is added, edited, or deleted, TOW records activity on the ticket so the history remains visible.

Activity​

Activity is the audit trail for a ticket. It records important system and user actions, including field updates, comments, links, unlinking, AI-applied changes, duplicate resolution, roadmap actions, and project moves.

Use the activity feed when you need to answer:

  • Who changed the status or assignee?
  • When did the priority or due date change?
  • Why was a custom field cleared?
  • Which AI or operating proposal made a change?
  • Was a ticket archived by duplicate resolution or roadmap regeneration?

Activity is especially important for regulated teams, customer delivery teams, and executives reviewing why a plan changed.

Links describe relationships between tickets without changing the hierarchy. TOW supports these link types:

  • relates_to: the tickets share context.
  • blocks: the source ticket blocks the target ticket.
  • is_blocked_by: the source ticket is blocked by the target ticket.
  • duplicates: the source ticket duplicates the target ticket.
  • is_duplicated_by: the source ticket is duplicated by the target ticket.

Use links when work is connected but neither ticket should own the other. For example, a backend task may block a launch task, or two customer requests may relate to the same product area.

When adding a link, you need write access to the source ticket and read access to the target ticket. TOW prevents a ticket from linking to itself and reuses an existing identical link instead of creating a duplicate relationship.

Blocking Links

Adding a blocks relationship may move the blocked ticket into a blocked status when the target project's workflow supports that status and transition. If the workflow does not allow the move, update the status manually or ask a project manager to adjust the workflow.

Remove a link when the relationship is no longer accurate. Removing a link records activity on the source ticket. It does not delete either ticket and does not undo work that happened while the link existed.

Before removing a dependency link, check whether people are using the relationship during planning or standup review.

Epics​

Epics are tickets with the epic type. Use an epic for a larger outcome that contains multiple tasks, stories, or bugs. Epics appear on the roadmap and show progress based on their child tickets.

Use epics for:

  • Customer implementation phases.
  • Product milestones.
  • Cross-functional delivery outcomes.
  • Large operational improvements.
  • Work that needs a timeline, dependencies, and child ticket progress.

Tasks, stories, and bugs can be parented by epics. Epics cannot be parented by another epic.

Subtasks​

Subtasks break a specific ticket into smaller execution steps. A subtask must belong under a task, story, or bug. Subtasks cannot be parented directly under an epic, and subtasks cannot parent other subtasks.

Use subtasks when the parent ticket is still the unit of planning but a few smaller steps need ownership or status.

Hierarchy Rules​

TOW enforces hierarchy so planning stays clear:

  • Epics contain tasks, stories, and bugs.
  • Tasks, stories, and bugs can contain subtasks.
  • Subtasks require a parent.
  • A ticket cannot be its own parent.
  • Parent and child tickets must belong to the same project.
  • Moving a ticket tree to another project keeps relationships inside the moved set and detaches parent links outside the moved set.
Project Moves and Custom Fields

When a ticket or ticket tree moves to another project, TOW clears project custom fields on each moved ticket. Project-specific values do not carry across because the target project can define a different custom-field schema.

Review Connected Work​

When reviewing a ticket, check these areas in order:

  1. Read the title and description for intent.
  2. Check the parent or epic for the larger outcome.
  3. Review links for dependencies or duplicates.
  4. Read recent comments for human context.
  5. Review activity for status, field, project, or AI-applied changes.

This flow gives a reviewer enough context to act without reopening old conversations.