Trackers

A tracker is the connection between a board and an external work-tracking system — Azure DevOps or Jira. When a board is connected to a tracker, cards can be linked to tracker items, and changes flow in both directions.

Use a tracker to keep planning and execution in sync without re-typing. The board is where you do the upstream thinking — story mapping, prioritization, slicing — and the tracker is where execution happens — sprints, capacity, backlog grooming. Each tool stays the source of truth for what it does best.

A board can have at most one tracker connection. The connection is set up by a workspace admin (credentials live in the workspace) and enabled per board. A board without a tracker is fully usable — cards just don’t sync.

What syncs

When a card is linked to a tracker item:

• The card’s title and status mirror the tracker item’s, and updates flow both ways.
• Card position, color, shape, outcome membership, and reactions are CardBoard-only — they don’t sync, because the tracker has no equivalent.
• Sync conflicts use optimistic concurrency: if you and the tracker both change a card at once, the first write wins and the second gets a notification with the latest state.

Provider behavior is the same shape across trackers, but each has quirks — ADO’s work item types vs. Jira’s issue types, ADO’s iteration paths vs. Jira’s sprints. Field mapping is configured per board.

The set of supported trackers is intentionally small. CardBoard supports the trackers customers actually use rather than every tracker on the market — better one well-supported integration than ten flaky ones.

Tracker writes require member identity

Editing a tracker-linked card — or importing/exporting against the tracker — requires the user to be a workspace member, not a guest. Every sync write is attributed to the member who made it, in both your tracker’s audit log and CardBoard’s. See Permissions.

For ongoing patterns — what to link, conflict recovery, migrating off a tracker — see Working with your tracker.