Tasks

This page is generated from the in-app guide content — edit featureToggleGuides and run pnpm gen:feature-toggle-docs.

Advanced task management

Completed work must be submitted for approval: the assignee submits, a reviewer scores the configured criteria and approves or requests revision before the task can be marked done.

How it works

Turns on review of task results: the doer submits, a reviewer scores against the company’s criteria and approves or sends it back. While on, In review and Done are reached only through submit/review. Required by Priority scoring.

When ON

Strict status matrix: moving straight to In review or Done is rejected (with a hint to submit for review); In review can go back to In progress/Cancelled; Done reopens only to In progress. The review section shows on task detail; a “waiting for my review” queue; review switches and scoring criteria appear in settings.

When OFF

Free status changes. Submit, withdraw, score and review prefill are rejected (feature disabled); review history stays readable. Priority scores stop updating.

Screens, documents and reports affected

Task detail (review section), status picker, Kanban board, completion tick, daily log, bulk edit, AI assistants, CRM stage-move card (linked tasks close as Cancelled instead of Done), review-score KPI.

Caveats

New companies start with this on. Tasks marked “no review needed” follow the free matrix on every surface; that value must be saved first — changing it in the same request as the status move does not open the gate. A new task cannot be created (or imported) in In review; it can be created in Done only when no review is needed (imported finished tasks are marked no-review automatically). The mobile apps have no submit/review step, so they disable Done/In review for tasks that need review. Moving a task out of In review without the review step (the way back to In progress, or any move once the switch is off) drops the open review round and logs it; turning the switch off closes no round by itself.

Example

An employee finishes “Q4 market report” and clicks Submit for review; the manager scores quality 4/5 and approves, and the task moves to Done.

Allow dependencies across projects

On: a task may depend on a task of another project. Off: same project only (a task without a project links only to tasks without a project).

How it works

Decides whether a task may depend on a task in another project. Checked at the single server gate that adds links.

Conditions for it to take effect

Requires “Enable dependencies”.

When ON

The predecessor picker lists tasks from every project; cross-project links are saved.

When OFF

Links only within the same project (tasks without a project only link to tasks without a project); adding a cross-project link is rejected as a policy violation.

Screens, documents and reports affected

Dependencies section on task detail, project Gantt, links added on task create, AI assistants, import.

Caveats

Turning it off deletes no existing cross-project links: they stay, are drawn dashed as “outside policy” and still count in the start/done gates. Moving a task to another project does not re-check its links.

Example

The “Website” project waits on “Finalise brand identity” in the “Branding” project: turn this on to link them.

Allow reviewing your own task

When off, the person assigned to a task cannot approve their own submission (separation of duties).

How it works

Decides whether the assignee may approve the work they submitted (only matters while Advanced task management is on).

Conditions for it to take effect

Requires “Advanced task management”.

When ON

Assignees can approve their own tasks; those tasks appear in their “waiting for my review” queue.

When OFF

An assignee scoring/approving their own task is rejected as a segregation-of-duties violation; their own tasks are left out of their queue.

Screens, documents and reports affected

Review section on task detail, waiting-for-my-review queue.

Caveats

The web review section hides Approve/Request changes from the assignee while off. If the resolved reviewer (designated reviewer, reporter or project owner) is the assignee, only another user with task-approve rights can decide. Past approvals are kept.

Example

A project owner works on a task in their own project: while off, another approver has to approve it.

Assignee required after Backlog

Only Backlog (and cancelled) tasks may have no assignee; To do and later need a person. A team alone does not count.

How it works

Only Backlog and Cancelled tasks may have no assignee; from To do onwards a specific person is required. A new task without a status goes to To do if it has an assignee, otherwise to Backlog. Checked on create and whenever an edit touches status or assignee, on every path (web, board, bulk edit, daily log, mobile, import, AI assistant, tasks created from meetings/playbooks/dunning).

When ON

Moving an unassigned task out of Backlog, or removing the assignee from a running task, is rejected with a missing-assignee error. Web and mobile disable those status options with a reason and hide remove-assignee/assign-to-team once the task has left Backlog. An unassigned parent task does not auto-start with its sub-tasks.

When OFF

As before: tasks from To do onwards may be unassigned, and a new task without a status goes to To do.

Screens, documents and reports affected

Task create form, list, Kanban board, detail, bulk-edit bar, daily log, mobile apps, follow-up tasks from overdue quotations, meetings, playbooks, dunning and AI assistants.

Caveats

On by default for every company. A team assignment or co-workers alone do not replace the main assignee. Existing unassigned tasks in To do or later are left as they are (no bulk fix); only their next status or assignee change is checked. With “Assignee required” also on, Backlog tasks need an assignee too.

Example

A team lead collects ideas in Backlog without owners; dragging “Redo pricing page” to To do asks for an assignee first.

Auto-watch on comment

Automatically subscribe a user as a watcher when they comment

How it works

People who comment on a task are added to its watchers so they get later notifications.

When ON

Commenting makes you a watcher of the task.

When OFF

Only people who click Watch (or are added) watch the task.

Screens, documents and reports affected

Comments and watcher list on task detail; task notifications.

Caveats

New companies start with this on. Turning it off does not remove watchers already added.

Example

An accountant comments with a question on “Pay supplier” and is notified when its status changes.

Automatic priority score

Compute a 0–100 priority score for each task from Impact, Urgency and Effort. Urgency and effort are derived from the due date and estimate; impact from project priority, OKR links and blocked tasks, or entered by hand. The formula and derivation rules are configured per company, with a preview before applying. Requires Advanced task management.

How it works

Computes a 0–100 priority score per task from Impact, Urgency and Effort (scale 1–5, manual input wins over inference). Urgency comes from days to due in company time; effort from estimated hours, story points or open sub-tasks; impact from project priority, OKR links, number of tasks blocked, tags, task type. Formula and inference rules are configured per company, versioned and previewable.

Conditions for it to take effect

Requires “Advanced task management”.

When ON

Score card on task detail, a score column and sort in the list, the formula settings page. Scores are recomputed after each task create/edit, dependency add/remove, config save, and by an hourly job.

When OFF

Card, column and settings page are hidden; settings/preview are rejected; manual impact/urgency/effort input is rejected (sending an empty value to clear still works); no recompute.

Screens, documents and reports affected

Task detail, task list, Tasks settings (priority score configuration).

Caveats

Missing data or a broken formula leaves the score empty with a status — it never stores a fake 0. Turning it off deletes no scores: they freeze; the list no longer sorts by score (default order instead). It does not change the priority label (low/medium/high) — that switch is not active yet.

Example

A task due tomorrow, linked to a quarterly KR and blocking 2 others scores 88 and tops the list when sorted by score.

Complete sub-tasks first

Block marking a parent task done while sub-tasks are still open

How it works

Blocks marking a parent Done while it has sub-tasks that are not closed (neither Done nor Cancelled).

When ON

Moving a parent to Done is rejected with the list of open sub-tasks, on every path (detail, Kanban board, completion tick, bulk edit, daily log, mobile, AI assistant). The web checks first and explains why.

When OFF

Parents can be closed regardless of their sub-tasks.

Screens, documents and reports affected

Kanban board, list, completion tick, bulk-edit bar, detail, daily log.

Caveats

Parents already Done are not reopened when you turn it on. Cancelled sub-tasks count as closed.

Example

“Prepare conference” still has “Print handouts” in progress: ticking the parent done is refused.

Enable dependencies

Allow links between tasks (finish→start, start→start, finish→finish, start→finish, with lag). Off: links cannot be added or removed and no dependency rule is checked; existing links stay and come back when turned on.

How it works

Enables dependency links between tasks: finish→start, start→start, finish→finish, start→finish, with a lag in days. Every add/remove goes through one server gate (no self-links, cycles refused). The other four dependency switches require this one.

When ON

Links can be added/removed on task detail, the create form and Gantt; “blocked” badges and Gantt arrows appear; start/done gates and rescheduling follow the child switches.

When OFF

The server rejects adding, removing and rescheduling links (feature disabled). No dependency rule is checked: no start warning, no done block, no reschedule proposal. The UI hides link buttons, arrows and badges; the dependencies section is read-only.

Screens, documents and reports affected

Task detail (dependencies section), create form, list, Kanban board, bulk edit, task and project Gantt, mobile apps (asked before a status change), AI assistants, import.

Caveats

Turning it off deletes no links: they stay and take effect again when turned back on. Turn the child dependency switches off first. Applying a project template while off does not copy the template’s links.

Example

“Installation” depends finish→start on “Delivery”: Gantt draws the arrow, and starting Installation early triggers a warning.

Enable sub-tasks

Allow nesting sub-tasks under a parent task

How it works

Allows sub-tasks under a parent task (two levels at most). The four sub-task switches (inherit defaults, dates within parent, parent progress, auto-start parent) depend on this one.

When ON

Sub-tasks can be created from the detail page, from the create form (choosing a parent) and when cloning with sub-tasks. The advanced sub-task switches can be turned on.

When OFF

Creating a task with a parent, or setting a parent on an existing task (edit, import), is rejected (feature disabled). Add-sub-task buttons and the parent picker are hidden; cloning copies no sub-tasks and a copy of a sub-task becomes a standalone task; project templates create flat tasks. The advanced sub-task switches cannot be turned on (turn them off before turning this off).

Screens, documents and reports affected

Task detail (sub-tasks section), task create form, clone, Tasks advanced settings.

Caveats

Existing sub-tasks keep their parent link and stay visible. Setting a parent by edit or import follows the same rules as creating a sub-task: two levels at most, same project, dates within the parent.

Example

An implementation project splits “System setup” into three sub-tasks for three people.

Enable time tracking

Allow logging estimated and actual hours / story points

How it works

Enables estimated hours, actual hours, story points and time logging on tasks.

When ON

Hours and story-point fields show on the form and task detail; the task time-log section works.

When OFF

Hours, story points and the time-log section are hidden. The server ignores hours/story points sent on create, edit and clone (no error); logging time through the task time-log section, the daily work log or per-person estimates is rejected (feature disabled); project templates copy no estimates.

Screens, documents and reports affected

Create form, task detail (progress card, time-log section, sub-tasks), clone.

Caveats

Turning it off deletes no hours or time logs. The daily log still saves status/progress; only hours are refused. Project time logging in the Projects app is governed by its own Projects switch.

Example

A marketing team that does not track hours turns it off for a leaner task form.

Enforce dependency completion

Block marking a task as done while its predecessors are unfinished — per link type: finish→start and finish→finish need the predecessor done, start→finish needs it started, start→start never blocks done.

How it works

Blocks marking a task Done while a prerequisite is not met for its link type: finish→start and finish→finish need the predecessor done; start→finish needs it started; start→start never blocks completion. Cancelled or deleted predecessors never block.

Conditions for it to take effect

Requires “Enable dependencies”.

When ON

Moving to Done (drag, completion tick, bulk edit, daily log, mobile, AI assistant, review submit/approve) is rejected with the list of blocking tasks. Web and mobile check first and explain why.

When OFF

Dependencies never block completion; “blocked” badges still show for reference.

Screens, documents and reports affected

Kanban board, list, completion tick, task detail, bulk-edit bar, daily log, mobile apps.

Caveats

Tasks already Done are not re-checked when you turn it on. Creating a task directly in Done (with links) is checked too. A sub-task is checked against its own links only; at completion it does not inherit its parent’s predecessors.

Example

“Acceptance” depends finish→finish on “Trial run”: while the trial run is open, dragging Acceptance to Done is refused.

Estimated hours with several people (co-work)

Per person: enter hours for each person; people without an entry share the rest evenly. Split evenly: the task estimate is divided equally.

How it works

How estimated hours are split when a task has an assignee and co-workers. Per person (default): hours are entered per person and whoever has none shares the rest evenly. Split evenly: the task estimate is divided equally among everyone.

When ON

Per person: the assignments card on task detail accepts hours per person; workload and project load use these figures.

When OFF

Split evenly: per-person hours cannot be entered (the server refuses to save them); load is split equally.

Screens, documents and reports affected

Assignments card and per-person hours strip on task detail, assignee picker (load), project workload.

Caveats

Switching to Split evenly does not delete per-person hours — they are ignored and used again when you switch back. A parent task only carries the estimate left after subtracting its sub-tasks’ estimates.

Example

A 10-hour task, An entered 6 hours, Binh none: Per person counts An 6, Binh 4; Split evenly counts 5 each.

Feed review scores into Performance

Approved task-review scores become the employee’s task_review_score KPI. That KPI prefills the Completion Evaluation, which feeds payroll — leave it off to keep the review gate purely a workflow control.

How it works

Approved review scores become the employee’s “task review score” KPI: a weighted average (by estimated hours, then story points) of each task’s latest approved score, reduced for each send-back round (down to 70% at most).

Conditions for it to take effect

Requires “Advanced task management”.

When ON

KPI syncs compute and store period data for this KPI; it prefills Completion Evaluation, which affects payroll.

When OFF

The KPI gets no new data; syncs skip it and do not overwrite existing figures.

Screens, documents and reports affected

KPIs and period data in the Performance app, Completion Evaluation, payroll parameters based on completion %.

Caveats

New companies start with this on. Requires Advanced task management: with reviews off the KPI gets no new data (past review scores included). Period data already written is not deleted when turned off.

Example

An employee has 5 approved tasks averaging 85, one sent back once: the period KPI records about 83 and shows in the quarterly evaluation.

Only the designated reviewer can review

When off, anyone with the tasks:approve permission can decide a submitted task even though the task names a reviewer.

How it works

When a task has a designated reviewer, only that person can decide the review (only matters while Advanced task management is on).

Conditions for it to take effect

Requires “Advanced task management”.

When ON

Anyone else — including users with task-approve rights — is rejected when scoring/approving (permission denied).

When OFF

The designated reviewer or anyone with task-approve rights can decide.

Screens, documents and reports affected

Review section on task detail.

Caveats

Tasks without a designated reviewer are still decided by approvers. The web review section shows decision buttons only to people this switch allows. No effect on existing data.

Example

A task names the QA lead as reviewer: while on, the project director cannot approve in their place.

Parent task progress

Manual: keep the % the user declared. Roll up by estimated hours / by count: also show a % computed from sub-tasks (never overwrites the declared %).

How it works

Chooses how a parent task’s progress is shown: Manual (default) uses only the % declared by users; By estimated hours or By task count adds a % computed from sub-tasks (cancelled ones ignored, done ones count as 100%).

Conditions for it to take effect

Requires “Enable sub-tasks”.

When ON

The progress card on task detail and the daily log also show the % rolled up from sub-tasks next to the declared %.

When OFF

Manual: only the declared % is shown.

Screens, documents and reports affected

Progress card on task detail, daily log.

Caveats

Display only: it never overwrites the declared progress % and stores nothing, so switching back and forth does not affect data. Reports and the API keep using the declared %.

Example

A parent has 4 sub-tasks, 3 done: By task count shows 75% next to the % the lead declared.

Require assignee

In every status except Cancelled (Backlog included) a task must have a specific assignee — checked on create and when status or assignee changes.

How it works

The strictest assignee rule: in every status except Cancelled a task must have one specific assignee. Checked when a task is created and whenever an edit touches status or assignee — every status path (board drag, bulk edit, daily log, mobile, import, AI assistant) goes through the same gate.

When ON

Creating or moving a task without an assignee is rejected with a missing-assignee error, even in Backlog. Assigning a team or only co-workers does not count as an assignee. Status pickers on web and mobile disable the options and show why.

When OFF

The lighter “Assignee required after Backlog” rule (if on) applies: Backlog tasks may stay unassigned.

Screens, documents and reports affected

Task create form, list, Kanban board, task detail, bulk-edit bar, daily log, mobile apps, the /task command in internal chat, tasks created from meetings, playbooks, dunning and Copilot.

Caveats

Off by default (new companies included). Paths that create tasks without an assignee (a title-only /task command, meeting action items without an owner, playbooks, dunning) are rejected while it is on; the follow-up task for an overdue quotation with no creator is skipped (and logged). Cloning keeps the original’s assignee (or the person cloning). Applying a project template skips this gate — template tasks are a plan in Backlog and are checked when their status changes. Existing tasks that already lack an assignee are left as they are and their title/dates stay editable; only their next status or assignee change is checked.

Example

An operations team wants every task to have an owner: someone creates “November stock count” without choosing an assignee, and the system shows an error and does not save it.

Require comment on status change

A comment is mandatory when changing a task’s status

How it works

Every task status change must include a note; the note is saved as a comment on the task.

When ON

Web and mobile open a reason dialog before every status change (including a status edit in the detail form); bulk edit uses one note for all rows; the daily log uses the row’s note; the AI assistant sends the suggestion’s reason. A status change without a note is rejected by the server with a missing-status-note error.

When OFF

Status changes need no note.

Screens, documents and reports affected

Status picker, Kanban board, sub-task completion tick, bulk edit, daily log, mobile apps, AI assistants.

Caveats

Review submit/approve steps carry their own note and need no extra one. Creating a task (not a status change) and deleting a task (its own action, moved to Cancelled) need no note.

Example

Moving “Fix login bug” to In review, the user writes “Fixed, waiting for QA” — it appears in the comments.

Require due date

Blocks creating a task without a due date and clearing the due date of an existing task.

How it works

Tasks must have a due date: checked when a task is created and when an edit clears an existing due date.

When ON

Creating a task without a due date, or clearing the due date of a task, is rejected with a missing-due-date error. The task create form (web, mobile) and the add-sub-task row mark the due date as required.

When OFF

The due date is optional.

Screens, documents and reports affected

Task creation (web, mobile, import, AI assistants), tasks created from meetings, playbooks, dunning, the /task command in internal chat, the add-sub-task row.

Caveats

Off by default (new companies included). Paths that create tasks without a date (the /task command, meeting action items without a date, playbooks) are rejected while it is on. Cloning copies the original’s due date (an original without one cannot be cloned). Applying a project template skips this gate. Existing tasks without a due date are left as they are and stay editable.

Example

Sales wants overdue work to be measurable: creating “Call back customer ABC” with an empty due date is not saved.

Reschedule dependent tasks

When dates change or a link is added (also on create and bulk edit) and a dependent now starts too early. A due date is the last working day, so finish→start means the day after. Ask: propose and wait for confirmation; Automatic: shift right away (duration kept, finished tasks and undated tasks never moved); Off: never shift — only a warning.

How it works

When changing a task’s dates (or adding a link, creating a task with links, bulk date edits, dragging on Gantt) makes a successor earlier than the dependency rule allows, the system builds a reschedule plan. The due date is the last working day, so finish→start means starting the next day. Three levels: Ask (default), Auto, Off.

Conditions for it to take effect

Requires “Enable dependencies”.

When ON

Ask: a proposal is returned and applied only after the user confirms. Auto: shifted in the same save, keeping durations; returns what was moved and what was skipped with a reason (outside scope/project rights, or outside the parent’s date window when that policy is Block).

When OFF

Off: never reschedules, only warns; calling the reschedule request directly is rejected (feature disabled).

Screens, documents and reports affected

Task detail, create form, bulk edit, task and project Gantt, the “Reschedule by dependencies” button.

Caveats

Done tasks and tasks without dates are never moved (dates are never invented); cancelled predecessors are ignored. Not retroactive: existing violations are proposed only on the next date edit or via the Gantt reschedule button. The mobile apps do not reschedule.

Example

Auto: “Delivery” slips 3 days and “Installation” (finish→start) moves with it, keeping its 2 working days.

Review score weights

Criteria the reviewer scores (1–5 stars) and each one’s weight in the overall score. Active weights must total 100%. Saved criteria cannot be deleted — turn them off instead, so past reviews keep their meaning.

How it works

The criteria reviewers score (1–5 stars) and each one’s weight in the overall score (0–100 scale). Up to 8 active criteria, and active weights must total 100%. A criterion can be marked for the system to suggest a score. Only matters while Advanced task management is on.

When ON

Approving requires a score for every active criterion; unknown criteria or scores outside 1–5 are rejected. The review section shows the configured criteria.

When OFF

Not configured: the four default criteria apply — Quality 35%, Volume 25%, Timeliness 25%, Effort accuracy 15%.

Screens, documents and reports affected

Tasks settings (criteria table), review section on task detail, review-score KPI.

Caveats

Saved criteria cannot be deleted — only deactivated, so past reviews keep their meaning (each review stores a snapshot of names and weights at scoring time). Changing criteria does not recompute past scores.

Example

A software company adds “Code quality” at 30% and lowers Volume to 15%; later reviews use the new set.

Show workload when assigning

Show: the people picker shows assigned hours / capacity in the task window. Warn: ask again when the person goes over capacity. Off: hidden.

How it works

The assignee picker shows each person’s load within the task’s date range: hours allocated / capacity / available. Capacity follows the work schedule, minus holidays and approved leave. Three levels: Off, Show (default), Warn.

When ON

Show: the picker shows the hours. Warn: also asks for confirmation when the chosen person is already over capacity.

When OFF

Off: load is neither computed nor shown.

Screens, documents and reports affected

Assignee picker on the create form, task detail and task drawer.

Caveats

Information only on the web — the server never blocks an assignment on capacity, even at Warn. Tasks without dates cannot be measured against a period.

Example

Warn: picking Minh for a task this week while Minh already has 42/40 hours asks for confirmation first.

Start the parent when a sub-task starts

When the first sub-task moves to In progress, a parent still in Backlog/To do moves to In progress too.

How it works

The first time a sub-task moves to In progress, a parent in Backlog/To do also moves to In progress (after the sub-task is saved).

Conditions for it to take effect

Requires “Enable sub-tasks”.

When ON

The parent starts with its sub-task. The parent’s move still passes the parent’s own gates (dependencies, assignee); if refused it is only logged and the sub-task stays saved.

When OFF

The parent keeps its status until a user moves it.

Screens, documents and reports affected

Every sub-task status path: detail, Kanban board, bulk edit, daily log, mobile.

Caveats

A parent without an assignee (when the assignee gate is on) or blocked by dependencies does not auto-start. Creating a sub-task directly as In progress does not trigger it.

Example

Dragging sub-task “Site survey” to In progress also moves parent “ERP rollout” to In progress.

Starting a task with unfinished dependencies

Applies the first time a task leaves Backlog/To do (to In progress, In review or Done). Finish→start: the predecessor must be done; start→start: it must have started. Sub-tasks inherit their parent’s dependencies. Off: no check; Warn: ask and allow; Block: refuse.

How it works

Checked the first time a task leaves Backlog/To do (to In progress, In review or Done). Finish→start: the predecessor must be done; start→start: it must have started. A sub-task inherits its parent’s predecessors at this step. Three levels: Off, Warn (default), Block.

Conditions for it to take effect

Requires “Enable dependencies”.

When ON

Warn: the web asks and then lets you continue; the server saves and returns a warning. Block: the server rejects with the list of unmet tasks; web and mobile explain before sending.

When OFF

Off: dependencies are not checked when starting.

Screens, documents and reports affected

Kanban board, list, detail, status picker, bulk edit, daily log (including entering progress on a not-started task), mobile apps.

Caveats

Only the first start counts: reopening a task or withdrawing a review is not checked; already-started tasks are unaffected when you change the level. Creating a task directly in a started status (with links, or as a sub-task of a parent with predecessors) is checked too.

Example

Block: “Paint walls” depends finish→start on “Plaster walls”, which is still open — dragging Paint walls to In progress is refused.

Sub-task dates outside the parent dates

Warn: save and notify; Block: refuse to save; Off: no check.

How it works

Checks that a sub-task’s dates fall within its parent’s date range, in both directions: when a sub-task’s dates are created/edited, and when editing the parent’s dates pushes open sub-tasks outside. Three levels: Off, Warn (default), Block.

Conditions for it to take effect

Requires “Enable sub-tasks”.

When ON

Warn: saves and shows a notice (for a parent: how many sub-tasks fall outside and the first one). Block: refuses to save as a policy violation; automatic rescheduling skips sub-tasks that would fall outside and says why.

When OFF

Off: not checked.

Screens, documents and reports affected

Task detail, sub-task create form, bulk date edits, Gantt, dependency rescheduling.

Caveats

Done and Cancelled sub-tasks are ignored. Switching to Block does not fix existing data: an out-of-range sub-task is only blocked on its next date edit (including an edit of the parent’s dates). Setting a parent by edit or import is checked against the new parent’s range too.

Example

Block: the parent ends 30 Nov; setting a sub-task’s due date to 5 Dec is refused.

Sub-tasks inherit from the parent

When creating a sub-task with empty fields: take the parent project, deliverable, assignee, priority and date window. The user can still change them.

How it works

When a sub-task is created with fields left empty, they are taken from the parent: deliverable, assignee (unless a team is assigned), priority and date range (only when both dates are empty). Users can still change them.

Conditions for it to take effect

Requires “Enable sub-tasks”.

When ON

Empty sub-task fields are filled from the parent on save.

When OFF

A sub-task carries only what the user enters.

Screens, documents and reports affected

Creating sub-tasks from task detail, the create form, AI assistants.

Caveats

The sub-task’s project always follows the parent regardless of this switch (sub-tasks must share the project). Applies at creation only; existing sub-tasks are not changed.

Example

Parent “Product launch” is High priority, assigned to Lan: adding sub-task “Write press release” with empty fields gets High priority and Lan.

Update priority label from score

Set the task priority (low/medium/high/urgent) from the score thresholds. A priority someone picked by hand is never overwritten.

How it works

Planned: set the priority label (low/medium/high/urgent) from score thresholds, never overwriting a label the user chose.

Conditions for it to take effect

Requires “Priority scoring”.

When ON

No effect yet: the switch is staged and nothing reads it.

When OFF

Priority labels are chosen by users as today.

Caveats

Turning it on or off changes nothing until the feature ships.