It would be really nice to have some custom fields.
Maybe Labels could address some of this, but I don’t think all use cases, otherwise the label list becomes long and unwieldy.
Labels are a great but they’re pretty clumsy for managing many categorisation needs.
I think that could be a good use case for a plugin (once we have a plugin api).
What use-case do you have that cannot really be solved with labels?
I’m thinking some attribute of the task.
It would likely change according to the namespace
So a task in a list in a namespace for Servers might need custom fields for RAM_Size, Disk_size, Host_platform
Whereas a task ina lis in a namespace for domains might need custom fields of registrar, dns_provider, client
With 4 x ram_size, 4 x disk_size, 4 x platform, 4 x registrar, 4 x dns_provider, 20 x client, you would have 40 labels. And it would only grow from there. 40 labels is a lot to manage, even with some colour-coding.
Side note : the text on a colored lable is not easy for me to read. Is there a way to increase font size ?
Anyway, maybe you have different way in mind to manage that kind of use case.
And sorry if I am missing the obvious in how to use the app for that.
Thanks for the clarification. I think that’s a good use case.
Hi I also think this would be a great addition, especially if you could see those fields in the list view and also sort by those fields. Maybe similar to the way ClickUp does it?
Hi @kolaente,
I just wanted to confirm—custom fields for tasks are still not implemented, right?
I’m considering taking a look at this feature. It would be helpful to have a PR or commit that introduces a new field to the task details schema and also integrates it into the UI components.
For example, let’s say there was a feature request titled “Add Priority Field”, and a specific PR was linked to it. If such a change exists, I could review it to understand:
- Which areas of the codebase were affected
- How schema changes were handled
- How the UI was updated accordingly
This would give me a starting point for incorporating custom fields logic in a similar way.
Is there any commit, PR, or high-level feature you could suggest as a reference?
yep.
I think all of the current fields were added without PRs. I can’t really check it because the search is broken on Gitea 
There is some documentation about the schema changes work and how to develop features in the docs: Development
Is there still interest in this feature from the community? I think this would be a great addition to the app!
App definitely need custom fields for tasks))
Signed up just to vote for this proposal. The ability to add custom fields / columns (and specifying the field type, e.g. text, choice, date, numerical value, currency with decimal places) is the only thing that preventing me from using Vikunja right now.
Somebody ping me if it ever gets implemented!
Yes, please! I would love to have this feature inside the Vikunja.
Would love to use RICE/DDD other frameworks in this.
Also, it helps with organization and indexing, so that would be great
UP for custom fields!
I also would like custom fields.
Hi everyone,
I’d like to propose adding support for custom fields in Vikunja. Currently, tasks are limited to the built-in attributes (priority, due date, labels, assignees, etc.), which works well for general task management but falls short for teams that need to track domain-specific data.
Use case examples:
**•** A recruiting team tracking “Candidate Source” or “Interview Stage”
**•** A content team tracking “Word Count” or “Publish Channel”
**•** A support team tracking “Ticket Severity” or “Customer ID”
Proposed functionality:
**•** Field types: text, number, date, dropdown/select (single or multi), checkbox, URL
**•** Fields definable at the project level, so different projects can have different custom fields
**•** Custom fields visible and editable in the task detail view
**•** Custom fields available as columns in the table/list view
**•** Filterable and sortable, same as native fields
**•** Optional: expose via API for integrations
Why this matters:
Many competing tools (Asana, ClickUp, Notion) offer this, and it’s often cited as a blocker for teams migrating to Vikunja from those platforms. It would meaningfully increase Vikunja’s flexibility for specialized workflows without touching its clean core design — as long as custom fields stay optional and off by default.
Open questions for discussion
**•** Should custom fields be scoped per-project or globally reusable across projects?
**•** Should there be a field limit for performance/DB reasons?
**•** Priority: is this better suited as a core feature or a plugin/extension once Vikunja has an extension system?
Curious to hear whether this has been discussed before, and what the maintainers think about feasibility given the current data model.