Functionality

Task dependencies

How to lock in the order of work between tasks: blocking tasks, preventing completion until they are closed, the "Blocked" label, and the filter in PRO-dela lists.

Updated September 29, 2026
Task dependencies

"First close the brief, then the design, then the markup" — this order usually lives in the task description, a comment, or a chat. The system knows nothing about it: the assignee completes a task that physically could not have been done, and the manager finds out where the work stalled by opening cards one by one.

In PRO-dela, the order of work can be locked in with dependencies: a task explicitly names its blocking tasks and cannot be completed until they are closed. Below is how to link tasks, what exactly is blocked, and where this is visible.

One link, two projections

A dependency is a single directed edge between two tasks of the same company. For the dependent task it is shown in the "Depends on" section, and for the blocking task — in the "Blocks" section. Both cards show the same link: by adding a blocker in one, you immediately see the dependent task in the other.

The link is created in the task card: the "Dependencies" block in the right panel, the "Manage" action, then the "Add links" section. Search finds tasks by name across the whole company, tasks of the current project are suggested first; you can select several at once. A task cannot block itself, and duplicate links are not created.

The gate stands only before completion

While a task has unclosed blocking tasks, it cannot be sent for review and cannot be moved to the "Done" status. This is a prohibition, not a warning with confirmation: an attempt to complete is rejected, and the interface shows the "Unclosed blocking tasks" section and lets you go to each of them.

Everything else is available even before the blockers are closed: changing the status to any other, assigning an assignee, participants, the timer, subtasks, editing fields. The dependent task is prepared in advance and waits for the blocker — only the final action is blocked.

Acceptance is protected by itself: it is performed on the completion record, which does not appear without being sent for review.

The block is lifted by closing the work

A blocker stops blocking when the work on it is closed — sent for review, accepted, or moved to "Done". There is no separate "unblocked" toggle: the state is computed from the current state of the blockers, so it is impossible to forget to remove it manually.

The assignee and the author of the dependent task receive a "Task unblocked" notification when the last blocker is closed. If there are several blockers and only one is closed, there will be no notification — the task is still blocked. The label in lists disappears without reloading the page.

The flip side of the same logic: if a blocker is reopened, the dependent task is blocked again — automatically, without manual actions. The "Task blocked" notification arrives when a task gets a new unclosed blocker; the initiator of the action does not receive a notification about their own action.

Rules and boundaries

Cycles are prohibited — both direct ones and ones through a chain of tasks. An attempt to create a link that would make a task reachable from itself is rejected with an explanation. Transitive blocks are not shown in the interface: the card shows only direct links, and the order is maintained by itself — "Markup" cannot be closed before "Design", and "Design" cannot be closed before "Brief".

Tasks can be from different projects of the same company; tasks from different companies cannot be linked. One task can have no more than 50 blocking and 50 dependent tasks. Permissions for dependencies are the same as for editing a task: there are no separate settings.

If a blocking task is closed by permissions, the link still applies and is shown impersonally, as "Unavailable task", without a name or link. It can be removed with the same "Remove link" button: a user should not be locked in a task because of an invisible reason. A deleted blocker does not block; restoring a task from the archive brings the block back.

Where this is visible in lists

Blocked tasks in lists carry the "Blocked" label. In the filters there is a "Blocking" group with the "Blocked" item — it shows everything that is stalled and why, without opening cards. The label and the filter work on all screens with a task list: the general list, project tasks, and the stage page.

Dependency changes are recorded in the history of both tasks, and open screens update without reloading the page.

Example: three tasks of one landing page

A website project has three tasks: "Brief", "Homepage design", "Homepage markup". The design card lists the blocker "Brief", and the markup card lists "Design". The markup assignee prepares the markup in advance, changes the status, and runs the timer, but the complete button is unavailable until the design is closed.

The designer sends the design for review — the markup is unblocked, the assignee receives a notification and completes the task. The review is rejected — the completion record is erased, the markup is blocked again, and the label returns to the list. No one toggled the block manually: it follows the statuses of the blockers.

What the gate does not do

The gate guarantees one thing: a task will not be closed before its blockers. It does not check the order of deadlines or the quality of work, and it does not draw dependency diagrams — there is no visualization in the platform, and only direct links are visible in the cards.

It is specifically the completion operation that is blocked, not access to the task: it can be opened, commented on, and moved through statuses. Canceling acceptance of an already accepted task does not bring the block back — the work on the blocker is recorded as closed. The block is brought back by reopening to "Pending" or by rejecting the review, which erase the completion record.

Frequently asked questions

Can I work on a blocked task?

Yes. The restriction stands only before completion: the status changes, an assignee is assigned, and the timer and subtasks work as usual.

What happens if a blocking task is deleted?

The link stops blocking; in the dependent task's card it is shown as "Unavailable task" and is removed with one button. Restoring the task from the archive brings the block back — the intention never went away.

Who can add and remove links?

The same person who can edit the task. There are no separate permissions for dependencies.

Is a blocker I don't have access to visible?

The task itself — no: the name and project are hidden, and the link is shown as "Unavailable task". The fact of the block is visible, and the link can be removed.

Lock in the order of work

Open the task card, find the "Dependencies" block, and click "Manage". Specify what must be closed before it — until those tasks are done, no one will complete it.

Sign up for PRO-dela. The current terms of use are available on the pricing page.