Task Definitions

A Task Definition configures one type of work. Its current rules apply to open tasks; there are no published Definition revisions or custom state machines. You need Tasks configuration access to edit it. Start with module setup if the catalog is unavailable.

Identity, mode and defaults

Create a Definition in Task Definitions and choose Direct or Queue mode. Direct uses Responsible as the performer. Queue uses Executor; its optional managing Responsible coordinates work without becoming its performer. Changing mode later requires another Definition.

The key identifies configuration; the display name is the readable label. Subject policy controls the task name. Number prefix and default priority apply to new tasks. A task’s issued number does not change when a Definition is renamed or its prefix changes. Numbers identify tasks; they do not determine Queue order. Priority and Sub-priority are signed 64-bit integers, including negative values.

Deactivation prevents new use where an active Definition is required. Deletion checks dependent work and configuration. Retire an Outcome that should no longer be offered instead of expecting deletion to remove its historical completion.

Data, Context and instructions

Each Definition owns two Part schemas. Input Data describes the request; Working Data captures execution results. Configure their fields and the forms/cards used on Task surfaces. Both Parts exist even with empty schemas. Field visibility, field edits and permission to edit the whole Part are separate checks. Task-owned Parts are not independent business Context records.

In Due date & Context:

• Choose Not used, Optional or Required at creation for Due date. Required means the Creator supplies a date before saving, not later at Start. No relative SLA or calendar calculation is implied by this setting.
• Add the admitted Entity Definitions or Boards before making Context required. Runtime selection chooses a concrete Entity Instance or Board Item. Managed projections and Task-owned Parts are not admitted Context families.
• For Direct work, decide whether Responsible is required at creation. Without Responsible, an eligible Owner is required. Starting always needs Responsible.

Instructions contains optional Markdown and ordered references to existing File Storage files. Select files here; this is not an upload destination. Authorized Task readers use the current bound instructions through the Task. That permission grants neither folder browsing nor editing of the source file. Disabled or empty instructions do not add an empty Task section.

Roles, eligibility and permissions

Use Roles & Assignments for three independent decisions:

Setting	What it controls
Operational role mappings	Which workspace roles are Creators, Observers or Task administrators for this Definition.
Participant admissions	Which active, user-linked Workers may be Owner or Responsible, using workspace roles or responsibility groups. Any listed source can admit a candidate; an empty list admits nobody.
Assignment actions	Which actors may choose initial participants or change them later. Assignment authority does not waive eligibility.

The Creator’s Worker can be suggested as Owner only when eligible. Being Owner does not make that person the Direct Responsible or Queue Executor. Queue Worker sources and dispatcher mappings are configured on the Queue.

For Queue mode, Responsible in Queue tasks can be Not used, Optional or Required at creation. Turning it off retains assignments/history, makes the participant operationally inactive and removes its configured grants after the required confirmation. Turning it back on does not recreate removed grants.

Permissions controls property and data changes by actor and state. An empty selection grants nothing. Rights from several applicable actors can combine, but an actor label does not bypass the command’s current state, validation, capacity or source-access checks. A configurable Done property permission is not a general reopen or historical-correction facility.

Execution and completion

The fixed states are Idle, In progress, Paused, Blocked, Postponed and Done. Use Transitions to enable supported pairs and their actors. Unsupported cells cannot be turned into arbitrary workflow edges. Pause is performer-only. Task administrator and Queue dispatcher are operational roles, not universal exceptions to the matrix.

Configure active Interruption reasons and Interruption policies together. Postpone uses a fixed delay and a per-task maximum; it needs an active applicable reason. Pause/block warning durations concern the current uninterrupted interval and do not prevent transitions. They are distinct from concurrent work limits.

Outcomes have their own actor grants. Completing a task must pass both the transition to Done and the selected Outcome’s permissions. Completion requirements govern that Outcome, including required Working Data, a completion comment or attachment evidence where supported by the editor.

The completion expression editor exposes the admitted fields, templates and operators for the installed language profile. Its roots include admitted WorkingData fields, Task.OutcomeComment and Evidence.HasAttachment; arbitrary Context traversal or unlisted fields are not implied. Validate the rule before saving. See the Task completion expression profile for examples, File presence checks, Cancel-outcome restrictions and date functions. A successful validation checks authoring, not whether a particular task already satisfies the requirement. Completion evaluates current saved data and records the decision. Referenced fields/rules have dependency guards; resolve reported references before destructive schema changes.

Done is terminal. There is no delivered general command to reopen the same task, recreate an attempt chain, purge history or apply retention holds through this editor. Do not model those effects as extra transition cells.

Collaboration and signals

Collaboration configures comments and files independently. Each channel chooses read sources, one owner for new content, related publication destinations and read/create permissions. Task and its admitted Entity/Board Context are the implemented sources. External Orchestrator placement is not a delivered resolver.

Enablement alone grants no access to Context content. Missing or inaccessible selected destinations can prevent publication; content is not silently redirected to the Task. Changing Context or policy does not move existing comments/files. Editing, deleting, downloading and quoting use the shared Collaboration rules.

An Signal profile binding on the Definition takes precedence over the Queue profile. Follow signals and notifications for steps, recipients, notification transitions and acknowledgement. Keep that configuration separate from Outcome and transition permissions.