How Deckgauge is put together
A board is a nested object model, not a flat table. Org trees, roadmaps, and connected sources sit next to it as their own entities — this page maps out how the pieces relate, so the rest of the docs make sense.
One board, two groups, and the columns a row carries.
What it does, and where the data comes from
A Board holds one or more Groups (colored buckets, ordered by position), and each Group holds Rows — the Project record underneath, whether you typed it in or a sync created it. A row's cells are a mix of built-in fields (owner, status, dates, CapEx/OpEx classification) and custom columns you add yourself — text, status, date, number, checkbox, dropdown, person, or link — whose per-row values are stored separately from the row itself. A board also remembers its own column layout: which columns are hidden and how wide each one is.
Views on a board
Every board has at least one Board-type view (the grid you land on), and can add Dashboard views (widget canvases) or a Roadmap view (that board's own groups laid out on a timeline). The tab bar at the top switches between these views on the left, and opens two board-wide sections on the right: Sources (what's connected and syncing) and Intelligence (the ClickHouse-backed analytics for that board).
Sources are attached per board
Connecting a tool is a two-step split: a connection holds credentials for one Jira site, GitHub org, GitLab instance, or Azure DevOps org, and a project sync names one thing to pull from it (a project key, a repo, and so on). Attaching that project sync to a specific board — with its own group, issue-type filters, and field mappings — is what actually puts synced rows on a board. The same connection and project sync can feed several boards without re-entering credentials; see Connecting sources for the full walkthrough.
Org trees and roadmaps are separate entities
An org tree is a people hierarchy — imported from Microsoft Graph or a CSV — that exists independently of any board, though a board can be scoped to one for a per-team workload view. A standalone Roadmap is likewise its own entity: it subscribes to groups from one or more boards, so a cross-board timeline can include work that lives on boards you don't otherwise touch. That's distinct from a single board's own built-in Roadmap view, which only ever shows that one board's groups.
Where the data lives
| Store | What it holds |
|---|---|
| Postgres | Boards, groups, rows, columns, sources, org trees, roadmaps, users, and access control — the system of record. |
| ClickHouse | Issues, transitions, pull/merge requests, and commits pulled by sources — the facts behind most dashboard widgets. A handful of board-state widgets (status distribution, items by owner, and similar) read the board's own Postgres rows instead. |
| Redis | BullMQ sync queues — transient job state, safe to lose between syncs. |
If it looks wrong
| Symptom | Cause | Fix |
|---|---|---|
| A board's URL 404s | Navigated straight to a bare /boards/… path | Use the canonical URL — /?boardId=… |
| The Intelligence tab is empty | No source on the board has intelligence enabled yet | Attach a source with code intelligence turned on, from the board's Sources tab |
| A standalone Roadmap is missing a board's items | That board's groups were never subscribed to the Roadmap | Open the Roadmap and add the board's groups |
Related
- Boards — creating boards, statuses, owners, and columns in more depth.
- Connecting sources — connections, project syncs, and per-provider credentials.
- Org trees — importing and using a people hierarchy.
- Roadmaps — cross-board timelines and the standalone Roadmap entity.
Last updated