Tasks
Overview
This page shows the tasks across all projects — grouped into lists, with subtasks.
Behind it sits a decision worth knowing, because it explains the behaviour in many places: a task and a ticket are not a separate pair but two flavours of the same object. Both are work items and differ only in their kind. That is why they share status, priority, ownership, history and comments, and why nothing is maintained twice — a task that turns into a customer request changes its kind and keeps its history.
Core tasks
Order tasks into lists. The default view groups by list. A task can be dragged to a new position within its list or into a different list. If you would rather not drag, focus the drag handle with the keyboard and reorder using arrow up and arrow down.
Capture quickly. At the foot of every list sits a New task… field — type a title, press Enter, done. Everything else can follow later.
Complete and reopen. Every row carries a tick to mark it done; completed tasks can be brought back with Reopen.
Filter and group. Filters for status, priority, list, assignees and project sit above the list. Besides the list view there is a table view with columns for title, list, status, priority, assignees, project, start, due date and last change.
Watch dependencies. If a task is blocked by another, the row says so rather than quietly letting you work on it.
Fields in detail
The What it does column answers what changes in the system — not what the field is called. The grey name behind the label is the API field: the same thing runs under that name through automation, import and AI tools.
A task and a ticket are the same thing in two shapes. Both therefore carry the same fields;
kinddecides which of them the mask shows.
Creating and editing a task
| Field | Required | Values / format | What it does |
|---|---|---|---|
Title title | yes | text, max. 1000 characters | The only required entry. Appears in list, board, notification and history. |
Kind kind | yes | task or ticket | Decides whether the record is kept as a task or a ticket — and with it the status catalogue, the mask and the visibility. Switching later is a genuine repurposing, not a detail. |
Description description | no | formatted text | What is to be done. Images and attachments are allowed. |
Status statusId | no | master data "task statuses" | Where the task stands. The category behind the status decides whether it counts as open, in progress or done — not the name. |
Priority priorityId | no | master data "priorities" | How urgent. Sorts the list and is the usual condition in automations. |
Assignees assigneeIds | no | several employees | Who does it. Several are allowed; everyone named sees it under My work and receives the notifications. |
Watchers watcherIds | no | several employees | Who wants to follow without being responsible. Watchers get notifications, but the task does not appear in their work list. |
Start startAt | no | point in time | When work should begin. The basis for planning and dependencies. |
Due date dueDate | no | point in time | When it must be finished. Passed and open means overdue — visible in list, board and reminder. |
Customer customerId | no | an existing customer | Who the work is for. The task appears in the customer record. |
Document type linkType | no | sales_order, invoice, quote — whatever the active document modules offer | Which kind of document the task belongs to — the basis of the follow-up on a document. Only together with the document; both empty removes the link. |
Document linkId | no | a document you may see | Which document. The task then appears in the Follow-ups card of that document and names it by its number. A document that does not exist or that you may not see is rejected. |
Project projectId | no | an existing project | Which project it belongs to. Only then does it count towards project progress and reporting. |
List listId | no | a list of the project | The column or group within the project. |
Position position | no | 0 or more | The order within the list. Set by dragging on the board; needed by hand only when sorting through the interface. |
Parent task parentUlid | no | identifier of a task | Makes the task a subtask. The parent's progress follows from its parts. |
Estimate (minutes) estimateMinutes | no | 0 or more | How long it should take. The counterpart to recorded time; the variance comes from both. |
Activity activityId | no | a time category | Which activity is booked for this task — consulting, development, support. Timer and time entry take it from here as long as nobody picks another. It is not the ticket queue, and without active time tracking it has no effect. |
Tags tags | no | several terms | Free grouping across project and status. |
Brand brandId | no | one of your brands | Assigns the task to a brand; without one it falls back to the default brand so it receives a reference number. |
Visibility visibility | no | normal or private | Private shows the task only to assignees and watchers. Meant for personnel matters, not as a substitute for permissions. |
Recurrence recurrenceRule | no | recurrence rule | Recreates the task after completion. The rhythm comes from the rule; without one it happens once. |
Definition of done definitionOfDone | no | checklist | The points that must be ticked. Visible in the task and, where configured, a precondition for closing. |
Dependencies
| Field | Values / format | What it does |
|---|---|---|
Target targetUlid | identifier of a task | The other task in the relation. |
Type type | blocked by, finish-to-start, start-to-start, finish-to-finish, start-to-finish | How the two hang together. Finish-to-start is the normal case: the other must be done before this one begins. |
Lag (days) lagDays | −365 to 365 | Distance between the two. Negative means overlap — the successor starts before the predecessor ends. |
Comment
| Field | Values / format | What it does |
|---|---|---|
Comment commentBody | formatted text | An entry in the history. Task comments run through the same history as mails and ticket messages — there is no second channel beside it. |
Attachments commentAttachmentIds | several files | Files for the comment. |
Interface and automation only
No mask carries these fields; they can be set through the interface, an import or an automation.
| Field | Values / format | What it does |
|---|---|---|
expectedText | text | Only when converting an entry of the definition of done into a subtask: the text the caller expects at that position. If it no longer matches, the conversion is rejected instead of hitting an entry someone has changed meanwhile. The interface sends it by itself. |
Settings & permissions
- Status and priority are master data, not fixed code. Shipped are Open, In progress,
Waiting, In review, Done, Cancelled, plus the priorities Low, Normal, High and Urgent. Both can be adjusted in the administration area.
- Permission
workitem.readto see them; creating and changing require the corresponding write
permissions. Where you lack a permission, the action is not shown.
- Visibility per work item. A work item can be flagged as not visible to external parties; the
list marks that.
- Plugins dock in here. Installed modules can add their own actions to the header. Which ones
appear depends on what is installed and released to you.
FAQ & troubleshooting
The view looks different from my colleagues'. The chosen view — lists or table — is remembered per person in the browser. Filters apply to you alone as well.
Dragging does not work. Dragging grabs the row's drag handle, not the whole row. The keyboard alternative: focus the handle, then arrow up or arrow down.
A task cannot be marked as done. Then a dependency is blocking it — the row says so. Complete the blocking task first.
Where are the tickets? Tickets are work items of the same family and appear in their own surfaces. This page shows the task flavour.