The point where a generic task list stops being enough

Most project boards give you a title, a status, and maybe a due date. That's fine until someone needs to track a day rate per task, or wants a column that shows total estimated hours across a whole epic without opening every task to add them up by hand. At that point the team either builds a shadow spreadsheet that duplicates the board — which drifts out of sync within a week — or the tool needs a way to add a field that isn't in the original schema.

Ten field types, two of which compute themselves

WKFGo's custom fields cover the usual ground — text, number, URL, date, dropdown, multi-select, checkbox, user — plus two that don't take manual input at all:

Rollup aggregates a numeric field across a set of tasks: sum, avg, min, max, or count, over built-in numeric fields like story_points, progress, or estimated_time. Point a rollup at an epic's subtasks and it recalculates automatically as those tasks change — no one has to remember to update it.

Formula does arithmetic on a task's own numeric fields: literals, + - * /, parentheses, unary minus, and identifiers that reference known numeric fields (including other custom fields). estimated_time * 1.15 for a padded estimate, or progress / 100 * story_points for points-completed, are the kind of thing it's for.

Why the formula evaluator matters more than it sounds

The tempting way to build a "formula field" is to run the expression through a language's own eval. WKFGo deliberately doesn't — the formula evaluator is a small, hand-written recursive-descent parser that only understands numeric literals, the four basic operators, parentheses, and identifiers that resolve to a real numeric field on the task. Anything else — a function call, an unknown identifier, a stray token, malformed syntax — is rejected outright with a validation error before the field is even saved. There's no code execution surface for a formula string to escape into, because the evaluator was never built to run code in the first place.

That's a deliberate trade-off: you can't write IF() or string manipulation into a WKFGo formula field. What you get in exchange is a formula field that's safe to expose to any user who can edit project settings, not just admins who are trusted with something closer to a scripting console.

Where this actually gets used

Setting one up

In Project Settings → Custom Fields, add a field, name it, and pick a type. For rollup, choose the numeric field to aggregate and the aggregation method. For formula, write the expression using the normalized names of existing numeric fields — the same name you gave the field is lowercased, with anything that isn't a Latin letter or digit collapsed to an underscore, so a field named "Day Rate" becomes day_rate in an expression. There's no separate reference name — the field's name is what both shows on the card and what a formula refers to. One practical consequence: a numeric field named entirely in Persian normalizes to nothing usable, so any field you intend to reference from a formula needs at least some Latin characters in its name, even on an otherwise Persian-language board. Required fields and dropdown/multi-select option lists work the same way regardless of whether the field is manual or computed. Computed fields show up wherever regular custom fields do — on the task card and in exports — they're just read-only, since there's nothing for a person to type into them.

Frequently Asked Questions

Can a formula reference another formula field? It can reference any known numeric field, including other custom fields, as long as the reference resolves to a number — but circular references (a formula that depends on itself, directly or through another formula) fail validation rather than looping.

What happens to a rollup if the underlying tasks are deleted? The rollup recalculates from whatever tasks currently match its scope — deleted tasks (including soft-deleted ones in the recycle bin) drop out of the aggregate automatically.

Is there a limit on how many custom fields a project can have? No hard cap, but every field adds a column to task exports and a row to the settings screen — past a couple dozen it becomes a maintenance problem for humans well before it's a performance problem for the database.

Can I change a field's type after tasks already have data in it? Changing type is possible but not lossless — going from text to number, for instance, only keeps values that parse cleanly as numbers. Treat a type change as a one-way migration, not a safe toggle.

Ready to track the numbers your board doesn't show by default?