Issues & tasks

Issues are the core of TaskFlow. An issue is a single unit of work — a task, bug, story or epic — that belongs to a project and moves through your workflow.

Creating an issue

From Issues or the Create menu in the top bar, choose to create an issue and fill in:

• Summary — a short title (required).
• Type — task, bug, story, epic, or whatever types your instance defines.
• Priority — from your priority scheme.
• Description — the details, with rich-text formatting.

Save, and the issue gets a key such as TF-42. Everything else is filled in on the issue page itself: assignee and co-assignees, labels — free-form tags for grouping — due date and story points, and any custom fields your administrator configured.

The issue detail page

Opening an issue shows everything about it in one place. Depending on which features are enabled, you'll find:

• Summary & description — edit inline.
• Status — the current workflow status, with a selector that only offers the transitions your workflow allows (see Workflow & statuses).
• People — assignee, co-assignees, reporter and watchers.
• Hierarchy — the issue's parent and its sub-tasks.
• Details — type, priority, labels, due date and custom fields.
• Comments — a discussion thread with mentions, replies and reactions.
• Attachments — files added to the issue.
• Links — relationships to other issues.
• Viewing now — who else has this issue open right now.
• Panels contributed by features you've enabled — checklists, worklog, SLA timers, dev links, releases, waves, approvals and CSAT.

Assignee and co-assignees

Every issue has one assignee — the person accountable for it. When work is genuinely shared, add co-assignees alongside them (up to 50 on an issue).

Co-assignees are a real field, not a convention: you can filter issue lists by them and automation rules can set them. Keeping a single assignee means "who owns this?" always has one answer, while the people actually working on it stay visible.

Parent and sub-tasks

An issue can have a parent, and any issue can be broken into sub-tasks. On the issue page you can assign, change or clear the parent, and create a sub-task directly from the parent — it inherits the project and opens ready to fill in.

Issue types can be marked as sub-task types. An issue of such a type always requires a parent, which is how you keep "sub-task" from drifting into being just another top-level issue.

Hierarchy vs links

Use parent/sub-task for breaking one piece of work into smaller pieces of the same work. Use links for relationships between separate pieces of work — blocks, relates, duplicates, cause.

Comments, mentions and reactions

Discuss the work in comments. Type @ and a name to mention someone — they get a notification and are pulled into the conversation. Comments can be edited and deleted, answered as threaded replies, and marked with reactions when a reply would just be noise.

Internal comments are visible only to your team. On a Service Desk request this is the difference between a note for colleagues and a reply the customer reads — see the Agent guide.

Attachments and links

• Attachments — upload files directly onto the issue. Files go straight to your instance's configured storage; the maximum size is set at deploy time (25 MiB by default). If attaching is unavailable, storage hasn't been configured yet — see File storage.
• Links — connect issues to express relationships such as blocks, relates, duplicates or cause. Linked issues appear on each other's pages.

Checklists

With the checklists feature enabled, an issue can carry one or more checklists — lists of items you tick off as you go; progress is shown per list and for the issue as a whole.

Checklists track work inside an issue; they don't move the issue itself. If you want "all items done" to change the status, that's an automation rule.

Time tracking

With the worklog feature enabled, an issue gets a Worklog tab where you log time spent and record an estimate. Entries are made by hand — there's no running timer — and they roll up into the worklog report for managers (see Reports & analytics).

Custom fields

Administrators can add custom fields — text, number, date, dropdown and more — to capture information specific to your process. They appear on the issue page as a dedicated Fields tab. Some can be marked required, in which case you must fill them in. Configuring them is covered in Project configuration.

Watchers

Watch an issue to be notified when it changes, even if you're not the assignee. Watching is manual — the Watch button on the issue page; an automation rule can also add watchers. Manage watchers from the issue's People section. See Notifications.

Workflow & statuses

Every issue has a status (for example To Do, In Progress, Done). You move an issue on with the status selector, which only offers the transitions allowed from the current status. This keeps issues moving through a defined process rather than jumping to arbitrary states.

Your administrator defines the statuses, the allowed transitions and which workflow applies where — see Project configuration → Workflow.

Filtering and sorting the issue list

The Issues list supports rich filtering and sorting:

• Filter across fields such as status, title, priority, assignee (a match on a co-assignee counts too), and created/updated dates, with operators like equals, not equals, greater/less than, contains and not contains. People are matched by id or email address.
• Sort by key, status, priority, assignee, or created date.

For searching across all projects, see Search & notifications.

Tips

• Give issues clear, searchable summaries — they show up in search, boards and reports.
• Use sub-tasks for decomposition and links for dependencies; the roadmap is built from hierarchy: an epic and its issues.
• Watch issues you care about instead of relying on being assigned.
• Put things colleagues shouldn't miss in a comment with a mention rather than in the description, which doesn't notify anyone.