Use Project Labels in Linear
Apply project labels to classify and filter the portfolio independently of issue labels. Agree on a short taxonomy before allowing near-duplicate categories to spread.
Step-by-step guide
Check access and scope
Workspace labels and team labels have different availability. Team-scoped project labels require an eligible plan and a project containing that team.
Choose taxonomy dimensions
List the portfolio questions labels should answer.
Create the label group
Create a workspace label group for a stable dimension such as product area.
- Worked example: Use Product area: Identity and Delivery type: Customer request as separate dimensions. Do not create Identity-customer-request as a combined label that becomes difficult to maintain.
Set selection behavior
Choose single-select or multi-select according to whether values can coexist. Project label groups are single-select by default; enable multiple values only for a dimension where combinations are meaningful.
Classify sample projects
Apply labels to a small representative project set.
Inspect the filtered portfolio
Create a filtered project view and inspect unlabeled exceptions.
Verify the result
The portfolio view returns expected projects and a project with multiple teams uses only valid label scopes.
Common mistakes
Avoid the main failure mode
Project labels do not automatically classify every issue independently. Readers must understand whether a filter targets issue labels or project labels.
Check the handoff edge case
Creating several labels for the same product area fragments portfolio reporting. Keep one accepted spelling and owner for the taxonomy.
Sources and verification
Based on product documentation checked on 2026-10-24. This is a documentation-based guide, not a hands-on benchmark. Features and availability can change.