Skip to main content

Project Boards

Project boards turn a project's ticket workflow into an operating view. Use boards for standups, triage, customer delivery, roadmap execution, QA review, leadership updates, and any recurring review that needs the same filter and layout.

Each board belongs to one project. It can have its own name, columns, TQL filter, visible issue types, card fields, card layout, and visual styles.

Default Board​

Every project has a default board. The default board follows the project workflow and generally excludes epics so day-to-day execution focuses on tasks, stories, bugs, and subtasks.

Use the default board as a starting point. Create saved boards when a team needs a different operating lens.

Saved Boards​

Create a saved board when a group repeatedly reviews the same slice of work. Examples:

  • Triage.
  • My team's active work.
  • Customer launch.
  • Bugs by severity.
  • Implementation blockers.
  • Review and QA.
  • Executive delivery view.

Saved boards reduce setup time and keep teams aligned on the same filters.

Board Columns​

Columns group one or more workflow statuses. A column has:

  • A name.
  • One or more mapped status keys.
  • A default status for tickets created or moved into the column.
  • A sort order.

When a ticket is moved into a column, TOW sets the ticket to the column's default status.

Hidden Statuses

Statuses that are not mapped to any column are hidden from that board. Tickets in those statuses still exist. Use list view, search, TQL, or another saved board to review them.

Map every status that needs regular review. Leave a status unmapped only when hiding it from that board is intentional.

Board Filters​

Boards use filters to decide which tickets appear. Simple board settings can filter by issue type and open work. Advanced boards use TQL.

Examples:

type != epic
type IN (bug, story, task) AND status_category != done
project = APP AND cf.customer_tier = enterprise AND assignee = currentUser()

Keep filters readable. A board should make the review easier, not hide important work behind a filter only one person understands.

Moving Cards​

Moving a card updates the ticket status. If the project uses restricted workflow transitions, the move must follow the configured transition graph and any transition rules.

Blocked Board Moves

A board move can be blocked by workflow rules. The destination may not be allowed from the current status, the user may need a higher project role, or required fields may be missing.

When a move fails, open the ticket and check the required fields. If the move should be allowed, a project manager can update the workflow transition.

Board Ownership​

Use separate boards for different operating questions instead of overloading one board. For example:

  • A delivery team board can show assignee, due date, and progress.
  • A triage board can show customer tier, severity, and age.
  • A leadership board can show milestone, owner, and risk indicators.

Review saved boards periodically. Delete or archive board definitions that no one uses so teams do not rely on stale operating views.

TQL and Project Scope​

Custom-field TQL requires a project scope. Since project boards are already project-specific, they are a natural place to use cf.<key> filters.

When copying a TQL filter from one project to another, confirm the target project has matching custom fields and workflow status keys.

Board Quality Checklist​

Before rolling out a board:

  1. Confirm the board purpose.
  2. Map all statuses that need review.
  3. Check the TQL filter against real tickets.
  4. Verify card fields support the review conversation.
  5. Test common card moves.
  6. Confirm restricted transitions and required fields behave as expected.

A good board gives the team confidence about what needs attention now.