Workspaces
Kanera organizes work around workspaces. A workspace is more than a folder for boards: it is the shared operating system for a related set of work.
Boards live inside a workspace, but the important setup belongs to the workspace. Lists, labels, custom fields, members, guests, and other shared configuration are available across the boards in that workspace. This makes Kanera different from tools where every board is configured independently.
What a workspace is
A workspace is the boundary where a team, department, client group, or operating process shares the same structure.
Use a workspace for work that should have:
- The same lists or workflow stages.
- The same labels and custom field catalogue.
- The same members, guests, and access model.
- The same automations or repeated processes.
- The same reporting and assigned-work context.
For example, an agency might keep all internal client boards in one Client Delivery workspace. Each client can have its own board, but every board uses the same lists, fields, labels, and workflow. Project managers can then see assigned work across the whole workspace instead of opening each client board one at a time.
How workspaces differ from board-first tools
In many board-first tools, each board is its own island. One board may have different lists, labels, fields, and process rules from the next. That can be flexible, but it often makes cross-board work harder to understand.
Kanera uses a workspace-first model:
| In board-first tools | In Kanera |
|---|---|
| Each board can have its own lists. | Lists are shared across the workspace. |
| Labels are often created per board. | Labels are shared across workspace boards. |
| Custom fields may differ from board to board. | Custom fields come from one workspace catalogue. |
| Cross-board views can be inconsistent. | Workspace views can group and compare work consistently. |
| Teams often jump between boards to understand workload. | Assigned Work shows what people are working on across the workspace. |
This model encourages consistency. More importantly, it lets Kanera show workspace-wide information in ways that are difficult when every board uses a different structure.
Why shared setup matters
When boards in a workspace use the same structure, Kanera can make better sense of the work inside them.
Shared lists help people compare progress across boards. If every client board has Intake, Active, Waiting, and Done, a project manager can scan the same workflow for every client.
Shared custom fields make grouping and aggregation more useful. A field such as Priority, Client, Risk, Effort, or Target Date means the same thing everywhere in the workspace.
Shared labels keep categories from drifting. A Blocked label or Needs Review label should mean the same thing no matter which board a card is on.
Shared membership makes assigned work clearer. People can review what each teammate owns across all boards in a workspace, prioritize work, and create new cards without hopping between disconnected board setups.
Boards inside a workspace
A board is where a specific stream of work is managed. Boards are useful for separating client work, product areas, campaigns, launches, queues, or recurring processes.
Create separate boards when the work needs its own conversation or surface, but still belongs to the same shared operating model.
Good board examples inside one workspace:
| Workspace | Boards |
|---|---|
| Client Delivery | Acme Onboarding, Brightlane Retainer, Northstar Launch |
| Product Team | Roadmap, Bug Triage, Release Planning |
| Marketing | Content Calendar, Campaigns, Website Requests |
| Operations | Facilities, Procurement, Internal Requests |
The board separates the context. The workspace keeps the process consistent.
Choosing workspace boundaries
Create workspaces around groups of work that should be managed consistently.
Good workspace boundaries include:
- A department, such as Product, Marketing, Operations, or Support.
- A team that shares one operating process.
- A client group that follows the same delivery workflow.
- A business unit with its own members, guests, and reporting needs.
- A sensitive area of work that should be kept separate from other teams.
Avoid creating a new workspace for every small initiative. If the same people use the same lists, labels, and fields, a new board inside the existing workspace is usually better.
When to use separate workspaces
Use separate workspaces when shared setup would create confusion or access problems.
Separate workspaces are usually better when:
- Different teams need different workflow stages.
- Custom fields mean different things in different departments.
- Guest access should be isolated.
- Client or business-unit data must not overlap.
- Reporting should not combine the work.
- Automations or process rules should be managed separately.
For example, a Product workspace and a Client Delivery workspace may both use a Priority field, but their lists, members, reporting, and day-to-day workflows may be different enough to keep apart.
Practical setup patterns
Start with one workspace when one team is learning Kanera or when the work naturally shares the same process.
Use multiple boards inside that workspace for different clients, initiatives, or work streams.
Standardize your workspace lists early. Lists are one of the strongest signals Kanera uses to organize work across boards.
Create custom fields only when the field will be useful across multiple boards. If a detail applies to one card or one board only, put it in the card description, checklist, or comments.
Review labels and fields before duplicating a process. Clean shared setup keeps every board easier to scan.