Labels vs custom fields vs custom statuses: when to use each
Most project management tools give you labels, custom statuses and custom fields. All three attach extra information to issues, but they solve different problems. Using the wrong one creates confusion instead of clarity.
This post breaks down labels vs custom fields vs custom statuses so you know when to reach for each one.
TL;DR: Labels tag and categorize issues (bug, frontend, urgent). Custom statuses define your workflow stages (Backlog, In Review, QA). Custom fields track structured data per issue (priority, effort, phase). Each solves a different problem. Use all three together.
What are labels, custom fields and custom statuses in project management?
Labels, custom fields and custom statuses in project management are three distinct ways to attach information to issues. Labels are lightweight tags for categorization. Custom statuses replace default workflow columns with stages that match your actual process. Custom fields add structured, typed data points like priority or effort to every issue in a project.
The confusion happens because all three add metadata to issues. But the type matters. A label says "what kind of thing is this." A status says "where is this in the workflow." A field says "what specific attribute does this have."
How do labels, custom fields and custom statuses differ?
Each one answers a different question about your work. Labels classify. Statuses locate. Fields describe. Here's how they compare side by side.
| Labels | Custom Statuses | Custom Fields | |
|---|---|---|---|
| Purpose | Categorize and tag issues | Define workflow stages | Track structured data per issue |
| Example values | bug, feature, frontend, urgent | Backlog, In Dev, In Review, Done | Priority: High. Effort: L |
| How many per issue | Multiple | Exactly one | One value per field, multiple fields |
| Visual on board | Colored tags on cards | Board columns | Colored badges on cards |
| Grouping | Views can be grouped by label | Views can be grouped by status | Not a grouping option |
| Best for | Quick filtering, cross-cutting categories | Modeling your workflow | Capturing structured data you can filter on |
The table makes one thing clear: they're not interchangeable. Using labels when you need statuses, or statuses when you need fields, is where most teams go wrong.
When should you use labels in project management?
Labels work best for categorization that cuts across your workflow. They answer "what kind of issue is this?" without implying where it sits in the process.
Good uses for labels:
- Issue type shorthand: bug, feature, improvement, documentation
- Area tags: frontend, backend, API, design
- Temporary flags: blocked, needs-discussion, quick-win
- Release markers: v2.1, sprint-12
Labels are flexible because any issue can have multiple labels at once. A card can be both "bug" and "frontend" and "v2.1" without contradiction. That's not true for statuses, where a card can only be in one stage at a time.
Labels also work well as view grouping criteria. You can group your board by label to see all frontend issues together, then switch to grouping by status when you want the workflow view back.
The risk with labels is sprawl. Without guidelines, "bug" and "Bug" and "defect" end up meaning the same thing. Keep your label list short and intentional.
When should you use custom statuses?
Custom statuses define how work moves through your process. They answer "where is this issue right now?" A card can only have one status at a time because it can only be in one place in the workflow.
Default statuses (To Do, In Progress, Done) are too vague for most real workflows. "In Progress" could mean a developer is writing code, a designer is reviewing mockups or a card is waiting for someone to pick it up. Custom statuses fix this ambiguity.
A software team might use: Backlog, In Development, Code Review, QA, Staging, Done. A content team might use: Draft, In Edit, Client Review, Approved, Published. Each status represents a genuine handoff point where work passes from one person or phase to another.
On a board view, custom statuses become your columns. The board shows your workflow, left to right. That's why getting statuses right has the biggest impact on whether your board is useful or just decorative.
For a practical example of custom statuses in action, see how to set up a client delivery board for agency projects.
When should you use custom fields?
Custom fields capture structured data that describes an issue's attributes. They answer questions like "how important is this?" or "how much effort does it need?"
Unlike labels, custom fields are typed. A single-select field gives you predefined options (High, Medium, Low). A number field captures estimates. A date field tracks deadlines. This structure means you can filter on the data consistently.
Unlike statuses, custom fields don't represent workflow position. A card's priority doesn't change just because it moved from In Development to Code Review. Fields describe the work itself, not where it sits in the process.
Common custom fields include:
- Priority: Low, Medium, High, Urgent
- Effort estimate: S, M, L, XL
- Project phase: Discovery, Design, Development, QA
- Feature area: Auth, Dashboard, API, Onboarding
Custom fields display as colored badges on board cards, giving you a visual layer on top of your workflow columns. You can configure which fields appear on cards in each view, so your board shows priority badges while your grid focuses on effort and phase.
For field setup ideas, check the guide on five custom fields every project manager should set up first.
What happens when you use the wrong one?
Using one feature where another belongs creates friction that builds over time.
Using labels when you need statuses
A team creates labels like "in-progress," "in-review" and "done" instead of using statuses. Now someone has to manually swap labels every time a card moves forward. Nothing prevents a card from having both "in-progress" and "done" at the same time. Labels don't enforce mutual exclusivity.
The fix: If a value represents a workflow stage and a card should only be in one at a time, use a status.
Using statuses when you need fields
A team adds "High Priority" and "Low Priority" as workflow statuses. Now their board has columns like Backlog, High Priority, Low Priority, In Development, Done. Priority isn't a workflow stage. It's an attribute of the work. Cards jump between priority and workflow columns, and the board stops making sense as a left-to-right flow.
The fix: If a value describes an attribute of the work rather than its position in a process, use a custom field.
Using labels when you need fields
A team creates labels like "effort-S," "effort-M" and "effort-L" to track estimates. This works until someone tags a card with both "effort-S" and "effort-L." Labels don't enforce single values. The data is technically there but it's unstructured.
The fix: If the value should be exactly one option from a predefined list, use a single-select custom field.
Worked example: a product team setting up a new project
A product team is starting a mobile app project. They have designers, developers and a QA engineer. Here's how they set up labels, statuses and fields to work together.
Custom statuses (the workflow):
Backlog, Design, In Development, Code Review, QA, Ready for Release, Done
These become the board columns. Each status represents a handoff point. When the designer finishes, the card moves to In Development. When the developer finishes, it moves to Code Review. Left to right, as a process.
Labels (categorization):
bug, feature, improvement, iOS, Android
A card can be both "feature" and "iOS." The team lead filters the board by "iOS" to see all iOS-specific work at a glance.
Custom fields (structured attributes):
| Field | Type | Options |
|---|---|---|
| Priority | Single-select | Low, Medium, High, Urgent |
| Effort | Single-select | S, M, L, XL |
| Feature area | Single-select | Auth, Home Screen, Settings, Push Notifications |
Each card gets a priority, effort estimate and feature area. These show as colored badges on the board. The team lead scans the board and sees red "Urgent" badges on two cards in the Backlog column. Those get pulled into Design first.
During the weekly planning meeting, the team switches to the grid view with status on the columns and assignees on the rows. They spot that Push Notifications has four L-sized items still in Backlog while Auth is nearly done. They adjust the plan.
Status tells them where work is. Labels tell them what kind of work it is. Fields tell them how important and how big it is. No single feature could do all three jobs.
How do labels, custom fields and custom statuses work in Eigenfocus?
Eigenfocus supports all three, configured per project. No global admin setup, no field schemes that affect other projects. Each project defines its own labels, statuses and fields independently.
Labels appear as colored tags on board cards. You can group any view by label to see issues organized by category. Create as many labels as you need per project.
Custom statuses become your board columns. Define the stages that match your actual workflow. Views can be grouped by status so the board reflects how work really moves.
Custom fields show as colored badges on cards. Create single-select, text, number, date, URL or boolean fields. Choose which fields appear on cards in each view, so your board stays clean while your grid shows more detail.
All three are per-project. If you run similar projects often, clone an existing project and its configuration carries forward.
If you're setting up a project from scratch and want to know how labels, statuses and fields fit together in practice, the project workflow setup guide walks through the full process step by step.
Tips for keeping labels, statuses and fields clean
- Review your labels quarterly. Delete labels nobody uses. Merge duplicates. A short label list stays useful longer than a sprawling one.
- Limit statuses to 5-8 per project. Fewer than five and you're back to vague buckets. More than ten and the board becomes hard to scan.
- Start with five custom fields. Priority, effort, phase, feature area and deadline status cover most workflows. Add more only when you need them.
- Don't duplicate across features. If you have a "Priority" custom field, don't also create "priority-high" and "priority-low" labels. Pick one feature for each piece of information.
Common questions about labels vs custom fields vs custom statuses
Can I use labels and custom fields together?
Yes. They serve different purposes and complement each other. Labels are best for quick categorization (bug, feature, frontend). Custom fields are best for structured data you want to filter on (priority, effort). Use both on the same issue without conflict.
Should I use a label or a custom field for priority?
Use a custom field. Priority should be a single value from a predefined list (Low, Medium, High, Urgent). Labels don't enforce single selection, so a card could accidentally end up tagged with both "priority-high" and "priority-low." A single-select custom field prevents that.
What's the difference between custom statuses and custom fields with a dropdown?
Custom statuses define your workflow columns. Moving a card to a new status moves it to a different column on the board. A custom field with a dropdown is metadata attached to the card. Changing a dropdown value doesn't move the card. Use statuses for workflow position and fields for everything else.
Can a card have multiple labels but only one status?
Yes. A card can have as many labels as you need (bug, frontend, v2.1) but can only be in one status at a time (In Development). This is by design. Labels classify. Statuses locate. A card can be many things but it can only be in one place.
How do I decide if something should be a label, a status or a field?
Ask three questions. Does it represent a workflow stage? Use a status. Does it need to be a single structured value you can filter by? Use a custom field. Is it a tag for quick categorization? Use a label. If you're unsure, default to a label. You can always promote it to a field later if you need the structure.
Get started with labels, custom statuses and custom fields
Set up all three per project, in minutes, with no admin overhead.
You can also read about how teams use Eigenfocus for software development or as a project management tool.