Task Tags vs Custom Fields

Tags and custom fields both look like extra labels on a task. They answer different questions. A tag says "this task belongs with these other tasks." A custom field says "this task has this value." If you use a tag as a value, or a field as a loose sticker, the task becomes hard to filter and easy to misread.

What a tag is

A tag is a workspace label you can put on a task. The same tag can appear on many tasks, including tasks in different projects in that workspace. That is the point: grouping across the workspace.

Use a tag for a shared topic that is not the project and not the status. Examples that usually work:

• A campaign name used by several projects
• A work type such as "bug" or "copy," if you truly filter that way
• A client name when several projects in one workspace serve that client

The tag does not hold a sentence, a number, or a person. It is the label itself. If you need the label to contain something, you wanted a field.

Tags are not statuses. Moving a task from To do to Done is a status change, described in how to set up task statuses. Adding a tag does not move the card.

What a custom field is

A custom field stores a value on the task. The types you can use are:

Type	What it holds
Text	A short line
Long text	A longer note
Checkbox	Yes or no
Number	A number
Currency	An amount, as a value only
Users	One or more people
Dropdown	One choice from a list you defined
Label	A label value on that field

You add the field because every task of that kind should carry the same kind of value. "Risk rating" as a dropdown is a field. "Needs legal" as a checkbox is a field. "External reference" as text is a field.

A currency field stores an amount. It does not create an invoice, a payment, or a revenue report. Dayzen projects do not bill clients. If someone treats the currency box as accounts receivable, they are wrong about the product. The box is a number with a money format.

A users field is not a second assignee system you should invent process around. The task already has assignees. Use a users field only when you need a different person-shaped fact, such as a reviewer named separately from the owner, and you have agreed what that means.

Choose with one question

Ask: am I grouping tasks, or am I storing a fact about this task?

• Grouping, and the same sticker will be reused: tag.
• A fact with a shape (yes/no, a number, a choice, a person, an amount): custom field.

"Q3 launch" on every task that belongs to that launch is a tag, if those tasks sit in more than one project and you need to see them together. "Approver" as a named person is a users field. "Launch" as a tag plus a free-text field that also says "Q3 launch" is duplicate clutter. Pick one.

Examples that go wrong

Priority as a tag. Priority is already Urgent, High, Normal, or Low. A tag called Urgent fights that field and will drift.

Status as a dropdown field. Status is the board. A second dropdown called Status will be updated half the time.

Client fee as currency, then a promise to invoice. The amount can sit on the task as a note for people who already know the commercial deal. It will not send a bill.

One tag per task, never reused. That is a custom text field wearing a tag. You gain nothing when you cannot click the tag and see a set.

A workspace that uses both

A studio runs three projects for one client and two internal projects.

• Tag: the client name, on the client tasks only, so a filter can show that client across the three projects.
• Dropdown field: channel, with the choices email, web, and print.
• Checkbox: "legal must read."
• They do not add a currency field, because they do not track fees in the project tool.

The internal projects do not get the client tag. They might still use the channel dropdown if the field was defined for the workspace and the choices fit. If the choices do not fit internal work, do not force the field. A field that is blank on half the tasks is a form nobody trusts.

How many is too many

Tags fail when the list is a junk drawer: colors, moods, and one-off jokes. Keep tags that more than one person will filter. Delete the rest.

Fields fail when every task opens into a form longer than the work. Start with one field you will actually read in a planning meeting. Add the next when a fact is being typed into the description every time.

Labels and dropdowns overlap in conversation. Use a dropdown when the task must pick one of a fixed set. Use a label field when the value is a mark on that field rather than a workspace-wide tag. If you cannot explain the difference to a teammate, you do not need both.

What neither one is

Neither tags nor custom fields replace sections, owners, or dependencies. A section is where the task sits in the project. An owner is the assignee. A dependency is Blocks or Related to. Putting "blocked" on as a tag hides the link that should exist between two tasks.

Neither one produces a report email. Filtering tasks is something a person does in the product. Do not promise a scheduled export.

Naming and cleanup

Name a tag as the thing you would type into a filter: the client, the campaign, the work type. Do not name it "misc," "important," or "new." Those words duplicate priority or status. Do not encode a date in a tag. The due date is the date.

Name a field as the fact: "Legal review," "External ID," "Channel." Avoid a field called "Notes" if the description already exists. Long text is for a structured note you want separately, such as a handoff comment with a fixed meaning, not a second description.

Once a month, look at tags nobody applied and fields that are empty on the tasks you opened. Remove the ones you cannot explain. A workspace accumulates stickers the way a spreadsheet accumulates columns. The cleanup is part of using them. It is not a reporting project, and it does not produce an export.

When two projects need the same dropdown, define the choices once and use them in both. When a third project needs a different choice, do not stretch the list with "other." A dropdown full of exceptions is a text field. Switch the type of fact rather than teaching people a code.

People fields deserve the same discipline. If "reviewer" and "assignee" are always the same person, delete the field and use the assignee. If they differ on real tasks, keep the field and say in one sentence what the reviewer is expected to do. A users field without that sentence becomes a second owner, and tasks start moving because the wrong name was filled in.

Conclusion

Task tags group work across a workspace. Custom fields hold a typed value on a task: text, long text, checkbox, number, currency, users, dropdown, or label. Use a tag when the sticker should match other tasks. Use a field when the task should store a fact. Never treat a currency field as billing. The place those tasks live is /pms.