Workspaces & Projects
Kanera organizes work in two main layers: workspaces and projects. Workspaces define the shared operating space for a team. Projects organize the actual work inside that space.
Workspaces
A workspace is the home for a team, company, department, or client boundary. It contains the projects, members, shared fields, labels, and settings that belong together.
Use a workspace to group work that shares:
- The same members or permission model.
- The same custom field catalogue.
- The same project templates or operating rhythm.
- The same reporting context.
- The same client or business unit boundary.
For most teams, one workspace is enough to start. Add more workspaces when separation helps people move faster or protects sensitive work.
Workspace settings
Workspace settings control the shared defaults for the team. Depending on your permissions, you can manage:
- Workspace name and visual identity.
- Members and invitations.
- Workspace-level custom fields.
- Shared labels and field options.
- Project organization.
- Billing or deployment-specific settings when enabled by your instance.
Keep workspace settings stable. Frequent changes to shared fields, labels, or project structure can make older work harder to interpret.
Projects
A project is a focused place to manage a stream of work. It can represent a product roadmap, sprint, client implementation, content calendar, bug triage queue, hiring pipeline, or internal process.
Projects usually contain:
- Lists that represent workflow stages.
- Cards that represent tasks, requests, bugs, decisions, or deliverables.
- Labels and fields for categorization.
- Owners, due dates, files, comments, and activity.
- Views that help the team scan and filter work.
Create a project when the work has its own rhythm, owners, or status conversation.
Choosing a project structure
Match project structure to how the team talks about progress.
| Workflow | Good project structure |
|---|---|
| Product development | Backlog, Ready, In Progress, Review, Done |
| Client delivery | Intake, Scoped, Active, Waiting on Client, Delivered |
| Bug triage | New, Reproduced, Prioritized, Fixing, Verified |
| Content production | Ideas, Drafting, Editing, Scheduled, Published |
| Operations | Requested, Assigned, In Progress, Blocked, Complete |
Avoid creating a list for every small status. If a status only applies to a few cards, a label or custom field may be clearer.
Workspace vs project decisions
Some configuration belongs at the workspace level because multiple projects should share it. Other configuration belongs inside a project because it only affects one workflow.
| Put it in the workspace | Put it in the project |
|---|---|
| Shared custom fields | Lists and workflow stages |
| Common labels | Project-specific labels |
| Team membership | Card owners and watchers |
| Cross-project standards | Board layout and view preferences |
| Client or department boundary | Initiative-specific work |
When in doubt, start at the project level. Promote structure to the workspace only after more than one project needs it.
Permissions and ownership
Workspace admins should keep the workspace clean and predictable. Project owners should keep individual projects current.
Good ownership habits:
- Give each project a clear owner.
- Archive projects that are no longer active.
- Review old lists and labels before duplicating a project.
- Keep workspace-wide fields useful across multiple workflows.
- Invite members at the narrowest level that still lets them do their work.
Common patterns
Use a single workspace with multiple projects when one team manages different initiatives together.
Use separate workspaces when client data, departments, or access rules should not overlap.
Use a template project when the same workflow repeats often, such as onboarding, launches, or client implementations.
Use project groups when the team needs a lighter way to organize many active projects inside one workspace.