Your tasks, your fields: custom fields per workspace
There’s a conversation that keeps coming up: “this works for me, but I need to note down the client on every task.” Or the amount. Or whether it’s been invoiced yet. Things that aren’t in a task tracker’s model and that are, nonetheless, half of your job.
Until now the way out was stuffing it into the title ([Acme] Review contract) or
creating one label per client. That works until you want to add up amounts, or
filter by what’s still unbilled, and you find out your data lives inside a string.
As of today you can define your own fields.
Five types, and that’s it
In Settings → Custom fields, a workspace admin creates the fields they need. Each one has a name and a type:
- Text — a client, a reference, a case number.
- Number — amount, hours, points. Decimals and negatives welcome.
- Date — delivery, expiry, signature.
- Member — who answers for this, without stealing the assignee’s seat.
- Checkbox — invoiced, approved, delivered.
There’s no endless catalogue of types, on purpose. These five cover what people were actually asking for, and each one stores its data as what it is: a number is stored as a number, so you can sort and compare it; a member is a real reference to that person, so if they ever leave the team the field empties itself instead of pointing at a ghost.
It’s per workspace, and that matters
The definition lives in the workspace, not the project. One workspace can have ten fields and another none: an agency that bills per client and a product team don’t need the same things, and they shouldn’t have to look at each other’s fields.
If a workspace defines none, nothing shows up. No empty block, no greyed-out section nudging you to fill something in. The feature doesn’t exist until you use it.
Where they show up
On each task, in the right-hand column, below the usual properties. Every field with the control it deserves: a calendar for dates, the same people picker as the assignee, a checkbox for yes/no.
As a list column, if you turn it on. That last part is deliberate: custom fields are off by default. Creating a field shouldn’t rearrange the whole team’s list without warning.
As a filter, with the operator that makes sense for the type: greater than on an amount, before on a date, contains on text, yes / no / empty on a checkbox. Filters are saved in your views, so “delivered but not invoiced” becomes one click instead of a manual search every Monday.
You can also group by a checkbox or member field. Not by text, number or date: grouping by a field with a different value on every task gives you a hundred groups of one, which is a worse list than the one you started with.
Empty is not zero
A small thing you feel immediately: leaving a number field blank does not store
a 0. “I haven’t filled this in” and “this is worth zero” are different, and
confusing them shifts an average or a total without you noticing. Same with the
checkbox: unchecked is not the same as explicitly “no”.
That’s also why an empty field draws nothing in the list. No dash, no filler zero.
The type doesn’t change
A field created as text can’t be turned into a number. We could have allowed it and converted whatever converts — but that means deciding on your behalf what happens to the values that don’t: thrown away? left half-done? The honest alternative is to archive the field (it stops being offered, it keeps everything already written) and create the new one.
Archiving, in fact, is almost always what you want instead of deleting. If you do delete, we tell you in how many tasks the value is about to be lost first.
Your agents see them too
If you work with agents over MCP, custom fields are theirs as well:
there’s a tool that discovers them (name, type, id) and save_issue writes them
like any other piece of task data. get_issue returns them already resolved.
With one rule we think matters: the type is validated against the definition. If an agent tries to put text into an amount field, it fails with a clear error instead of storing it wrong. Badly typed data that slips in quietly is the kind you discover three months later, when a report doesn’t add up.
And when you export a project to CSV, each field is one more column with its name in the header. Dates come out as dates and members with their name, not an id that means nothing to whoever opens the file in a spreadsheet.
One more thing: the order is yours
Field order is dragged in Settings, and that’s the workspace default. But each project can have its own: drag the fields on a task and that project remembers it. In the billing project the amount may come first; in support, the client.
It’s available now. If you had a piece of data living in your task titles, this is the moment to get it out of there.