Task Setting and Execution Control in PRO-dela: How the Task Lifecycle Works

A task in PRO-dela is the basic unit of work execution within a project: it has an author, an optional executor, a status, an optional priority, and a full lifecycle from setting to acceptance of the result. Below is the technical structure of this cycle: how a task is created, prioritized, divided into subtasks, assembled from a template, assigned, changes status, goes through completion and acceptance, receives an estimate and attachments, is embedded in a project stage, and ends up in the archive.

This is not an overview of "why you need a task tracker," but an analysis of task setting and execution control at the level of specific states and transitions between them — what actually happens to a task in PRO-dela from the first save to closure.

What a task includes and how it is created

A task supports full CRUD: create, view, edit, and delete. When creating, the project to which the task belongs and the title are mandatory — either a short title or free-form task text if the company has intelligent task creation enabled. Other fields — description, category, deadline, and priority — are optional and can be added immediately or later through regular editing.

The executor is not mandatory at the time of creation: a task can be saved without an executor and assigned later as a separate action when it becomes clear who will perform it. This separates two different decisions — "what needs to be done" and "who will do it" — instead of forcing the task setter to know both answers right away.

Priority: an optional field, not a mandatory classification

A task can have one of three priorities — high, medium, low — or no priority at all. This is intentionally an optional field: an empty selection in the interface returns the task to a "no priority" state, rather than substituting a random default value.

Priority can be edited by a regular task update at any time and participates in list filtering — you can show only high-priority tasks in a project, stage, or in the personal "My Tasks" list. However, priority intentionally does not affect the order of cards, manual sorting, or drag-and-drop: it is a separate classification axis, not a mechanism that secretly rearranges tasks when importance changes.

Subtasks: decomposing work within a task

Subtasks exist as a nested resource of a specific task: each subtask has a title, an optional description, and its own display order. They can be added, edited, deleted, and dragged independently of the parent task — a large work item turns into a clear list of steps without expanding into separate full-fledged tasks where it is not needed.

A subtask can be finished separately from the parent task — this is convenient when part of the work is already done while the rest is still in progress, and the team needs to see intermediate progress rather than waiting for the entire task to be closed.

Task and subtask templates

There is no need to manually assemble a recurring work structure every time. Task templates and subtask templates are independent entities with their own CRUD: they can be set up in advance and reused across different projects.

There is also a reverse path: an existing task along with all its subtasks can be saved as a template in one action — the title, description, and subtask structure are transferred automatically. Creating a new task from a template, in turn, only requires selecting the template and the project: then PRO-dela automatically expands the task and related subtasks according to the saved structure.

Assigning an executor and task participants

An executor can only be assigned from among the project participants — by a specific employee or by a user for whom PRO-dela itself finds the appropriate participant record in that project. Simultaneously with the assignment, you can set the starting status from which the task will begin for the new executor.

Separately from the executor, a task has participants: they can be added and removed, and this expands access to task details, the task chat, and notifications without making the person a formal executor. This allows you to add an observer or a second specialist to the task without reassigning the responsible person.

Who exactly on the team has the right to assign an executor, change status, complete, and accept a task is determined by the participant's role in the project; more details in the article "Roles and Team Members".

Task status and rules for changing it

Statuses belong to a specific project, so a task cannot be assigned a status from another project. A status can only be changed after the task already has an executor — otherwise, the system has nothing to tie the current execution process to.

For a completed or already accepted task, manual status change is limited: the only available transition is back to the "Pending" status, and this action automatically removes the completion mark. This protects against a situation where a task is "moved" by status bypassing the actual acceptance of the result.

Acceptance lifecycle: finish, accept, decline, reopen

Completing work (finish) is a separate action by the executor or another participant with the appropriate right. It records the completion date and can immediately assign a specific acceptor among the project participants — but not the task executor themselves, as the same person cannot check their own work.

Then the decision is up to the acceptor: they either accept the result (accept) or reject it (decline) and return the task to work, removing the completion mark and notifying the executor. If a task was accepted by mistake, it can be returned to work via reopen — a separate action that removes the acceptance confirmation.

Thanks to this, "the executor considers the work done" and "the result has been accepted" remain two different, clearly distinguishable states with their own action history — rather than a single "done" checkbox.

Task estimates: hours or cost, with confirmation

A task estimate is an independent entity with a type of "hours" or "cost" in a specific currency and an optional description. A task can have multiple estimates: they can be created, edited, and deleted.

Estimate confirmation is a separate confirm/unconfirm action, available not to everyone but to a participant with the right to confirm estimates in the project — typically the client side — or the project author. A confirmed estimate and the removal of confirmation are visible in real-time to everyone with access to the task, turning the estimate into an agreed-upon commitment rather than just the executor's guess.

Task order: drag-and-drop in three independent areas

Manual sorting of tasks in PRO-dela works not in one but in three independent areas. In the personal "My Tasks" list, the order is personal — each user has their own. Within a specific project, the order is common to everyone who sees that project's list and is stored separately from the order within an individual stage. Subtasks are sorted by their own drag-and-drop within their task.

Once the list is sorted not manually — for example, by priority, creation date, or acceptance date — drag-and-drop for that view is hidden: manual order and server-side sorting are deliberately not mixed to prevent cards from "jumping" under two logics simultaneously.

Task archive: restoration and permanent deletion

Deleting a task is archiving, not instant data disappearance. A user with the right to delete a task, after deletion, has two separate actions available: restore the task or permanently delete it (force delete). This protects against accidental clicks: mistaken deletion is not final but a reversible state.

An administrator additionally sees their own archived task list across the entire platform — with its own sorting, viewing, restoration, and final deletion of already archived records, regardless of who archived them and in which project.

Task attachments

Files are attached directly to the task and stored as protected attachments, not as public links to media files. Before serving a file, access to the task itself is always checked, and that the requested file is indeed part of that task's attachment set — opening someone else's attachment by a guessed identifier is not possible.

Preview and download are different operations: preview serves the file for viewing directly in the interface, download serves it as a regular download to disk. This is convenient for quickly checking a layout, screenshot, or PDF without the extra step of "download → open → delete."

Technical specification and connection to project stages

A task has technically the same field that is usually called a technical specification: a detailed description that is edited in a separate text editor with formatting directly on the task page. It lives alongside the technical specification of the entire project and the technical specification of a specific stage — resulting in three levels of detail, from the overall project concept to a specific executable task.

A task can be attached to a project stage and detached back; an attached task is embedded in the overall timeline of the stage along with other tasks of that phase, helping to see work not only as a list but also in the context of the current project phase.

Progress, expenses, and roles — where to find details

In addition to statuses and estimates, a task has a separate layer of actual accounting — progress and expenses, which later become part of the project's budget statistics. This is an independent topic with its own confirmation logic, so a detailed analysis is in the article "Time and Expense Tracking for Tasks".

And which specific actions with a task are available to a particular participant — from assigning an executor to confirming an estimate — is determined by their role and rights in the project; the detailed structure of roles and rights is described in the article "Roles and Team Members".

Frequently Asked Questions

Is priority mandatory when creating a task?

No. Priority is an optional field: a task may have no priority at all, and this is a separate, full-fledged state, not a "low priority by default." Priority can be added or removed at any time through regular task editing.

Do I need to assign an executor immediately when creating a task?

No. Only the project and title (or task text in intelligent creation mode) are mandatory for creating a task. The executor can be assigned immediately or later — as a separate action when it becomes clear who will perform the work.

How is "task completed" different from "task accepted"?

These are two different states with different actions. Completion (finish) records that the executor considers the work done and can assign an acceptor. Acceptance (accept) is a separate decision by the acceptor: they either agree with the result or reject it (decline) and return the task to work. An already accepted task can be returned to work via reopen if necessary.

What happens if I delete a task by mistake?

A deleted task does not disappear immediately: it goes to the archive, from where it can be restored. Permanent deletion (force delete) is a separate, deliberate action, not an automatic consequence of regular deletion.

Can I avoid manually repeating the same task structure every time?

You can use task and subtask templates: set up a template in advance or save an existing task along with its subtasks as a template, then create new tasks from that template in one step.

Start with one task

Register in PRO-dela, create your first project, and add a real task to it — with a priority, executor, status, and, if needed, subtasks. This shows how execution control works faster than any feature description.