Concepts
Data model
How workspaces, teams, issues, projects, initiatives, and cycles relate — one schema underneath every view.
Last updated
Everything in Planoda hangs off one schema. Boards, lists, roadmaps, and the API are views over the same rows — there is no separate 'board database' to sync with a 'tracker database'. Understanding the shape makes the whole product predictable.
The hierarchy
From the top down: a workspace contains teams; a team owns issues, boards, lists, and cycles. Issues can belong to a project; projects can belong to an initiative. Labels, priorities, and workflow states decorate issues.
workspace
└─ team (key: ENG)
├─ board / lists / cycles
└─ issue (ENG-1042)
├─ workflow state · priority · assignee · labels · estimate
└─ project ──▶ initiativeOne issue, many views
Because the board column is the issue's workflow state and the roadmap reads the issue's project and cycle, every view is derived rather than duplicated. Move an issue on the board and its row changes once; the list, the roadmap, the API response, and any subscribed client all reflect it.
Stable identifiers and history
An issue's identifier (ENG-1042) is stable for its lifetime regardless of how it is re-homed. Its history — state changes, reassignments, comments — is retained, which is what makes cycle retros and audit review meaningful.
Related
- Workspaces & teamsHow workspaces, teams, and team keys are organized — and how membership maps to what people can see.
- Roadmaps & initiativesPlan above the team line: group projects into initiatives and track them on a roadmap.
- Permissions & RLSTenant isolation enforced in Postgres with row-level security — the same boundary for the UI, the API, integrations, and AI.