Work management
Labels, fields and attachments
What you can record about work beyond the built-in columns — and the two settings changes that are refused.
Three ways to put more on a work item, answering different questions. Reaching for the wrong one is the usual mistake, so it is worth two minutes.
- Label
- A flat, shared word. One list for the whole organisation, no structure. Good for cross-cutting things a schema will never model:
regression,needs-design,blocked-on-client. - Custom field
- A named question with a typed answer, asked on the kinds of work you choose. Good for anything you will later want to filter, sort or report on.
- Attachment
- A file. A screenshot, a log, an exported design.
Which one
Reaching for a label where a field is meant produces client-helix, client-meridian, client-orbit and no way to ask which client an item is for. Reaching for a field where a label is meant produces a dropdown nobody maintains.
Labels
Organisation-wide, not per project — the same reason the backlog and sprints are. The whole point is that regression means the same thing on every client's work, and a per-project list would give an agency fifteen copies of it that no filter can bring together.
Deleting a label removes it from the work carrying it, and you are told how much that is before it happens. Nothing points back at a label to explain a past decision, so unlike a leave policy or a checklist template there is no history to preserve.
Custom fields
A field has a key, a name, a type, and the item types it is asked on. Nothing chosen means every type; a field scoped to bugs does not appear on an epic, because a form that asks for everything gets filled in with nothing.
| Type | Answer |
|---|---|
| Text / Long text | Free text. |
| Number | A figure you can filter and sort on. |
| Date | A day. Stored and rendered in UTC, like every other date here. |
| Checkbox | Yes or no. An unticked box is stored as *no*, not as *unanswered*, so a filter for what is not ticked finds it. |
| One choice / Several choices | From a list you define, each with its own colour. |
| Web address | A link, checked to be one. |
| Person | Somebody in the organisation. |
Two changes are refused once a field is in use
The key never changes, because saved views filter on it. The type cannot change once values exist: those values are stored in the form the old type named, and the new type reads somewhere else — every item would show the field as empty while the data was still in the table. Renaming the label is always allowed, because that is the part people actually want to change.
Required applies when work is created, never afterwards. Adding a required field does not invalidate the ten thousand items that predate it. Nobody would go back and fill them in, so the practical effect of the other choice is a backlog nobody can edit.
Removing a choice somebody has already picked is refused, and deleting a field that holds values hides it instead of deleting it. Both would blank data with nothing recording what it held.
Attachments
Files upload from the browser straight to storage through a short-lived signed URL, so a fifteen-megabyte screen recording never occupies an application server. What actually arrived is then read back from storage rather than believed from the browser.
Nothing is served publicly
Every read goes through an authorised redirect to a five-minute signed URL, and always as a download rather than rendered in place. A work item carries customer data as routinely as anything else, and a file on a guessable path is readable by anyone who ever saw one link.
Executables are not accepted. Nothing here is served from a path a browser will run, but an attachment is a file one colleague hands another, and being the delivery mechanism is bad enough on its own.