A task dependency exists when one result is needed to perform another task. Identify the direction and specific unblock condition. Similar subject matter alone does not create a blocker, and a predecessor’s completed status does not always mean the required input is ready for the next step.
Distinguish a shared topic from a required predecessor result
Task A approves offer copy; task B publishes that offer. B requires a particular approved version from A. That is a real dependency.
Task C changes an icon elsewhere on the site: it may be related but need not wait for the copy. Do not turn similarity into an automatic sequence that stops independent work.
Complete: “B cannot perform the agreed step until A supplies …”. If you cannot identify a missing result, consider whether the relationship should merely indicate a connection. From request to task covers the general move into work. Here the concern is a specific obstacle between tasks whose outcomes are already identified.
Scroll the table sideways to see all columns.
| Task pair | Meaning |
|---|---|
| Approve copy → publish offer | The first supplies a condition required by the second. |
| Publish offer → approve copy | The reversed direction does not describe this process. |
| Change icon and write copy | A shared project does not automatically create a blocker. |
| Two cards for the same outcome | Check duplication instead of inventing a sequence. |
| Prepare layout and insert copy | Some work may be independent of finished text. |
Read the direction from both sides: A blocks B, and B is blocked by A. Another contradictory connection is unnecessary. A shared description helps both people understand the same dependency instead of creating separate condition lists. Task names should identify outcomes rather than merely departments, so the relation remains meaningful to someone outside the immediate conversation.
Give the blocker a particular input and boundary
“Waiting for copy” is vague when three copies contain different scope. A condition could be approved version B of the offer text for page A, with complete headings and links. This does not automatically mean all company documentation. The input must match the step that needs to start, not a general request for every available asset.
Record: “Offer publication is blocked by the copy-approval task. Unblock condition: version B is explicitly identified as approved and includes every element for this view. A draft alone is insufficient. Layout preparation can continue separately, but unapproved text must not be published.” This is a proposed process description rather than an automatic tool rule.
Identify the person supplying the result and the person starting the next step. This does not require designing a complete assignment system. The particular blocker needs a recipient and handover condition. For dependencies arising from a customer bug, the customer bug task template covers useful input context without replacing the unblock condition.
If the condition is a decision, do not describe it as receiving a file. The file may be available but unapproved. “We received the document” differs from “the applicable version was selected”.
Preserve that distinction so someone does not start the next stage prematurely. The needed approval should be explicit in the record rather than inferred from attachment availability.
Check the result before declaring dependent work ready
The predecessor’s status may mean completion under another scope. Check the expected input before unblocking. If A supplied only a heading while B needs the complete offer, the relationship still describes a gap. Do not transfer a green status into readiness for another task without comparing its particular condition and the delivered result.
- Read the recorded condition.Check exactly what the dependent task needs. Do not judge readiness solely from its name or a column change.
- Verify the delivered result.Establish version, scope and approval needed for this step. A partial draft is not a complete publication input.
- Confirm further work is possible.The next performer should know which input applies. Resolve differences before they start.
- Update the relation and description.Record the check result and remaining or removed blocker. “Done” alone does not explain a changed condition.
Team message: “The copy task supplied version B and confirmation of its scope. We checked the offer-publication condition; the required input is available. Publication can start with that version. Other unapproved documents are outside this input.” Use this after an actual check rather than as an automatic declaration triggered merely by another card changing status.
Separate work possible now from the blocked step
Missing approved text need not stop a sample layout being prepared. Permission for the layout does not permit publication. Describe the boundary of work possible now.
This prevents waiting for an entire project unnecessarily or bypassing a dependency essential to the final outcome. Each person should know which action remains unavailable rather than assume the whole task has stopped.
If one task mixes independent work and an input-dependent step, consider separate cards for actual outcomes. Do not split every action into a task.
The division should clarify the blocker rather than multiply the list. Preserve source and relationship between the parts so the next person can still understand why the division was made.
When two tasks block one another, inspect the process description. Both may need an earlier decision, or one may need to provide a draft rather than a final version.
Moving statuses does not resolve that contradiction. Identify the first available result, then correct relation direction. A circular record can reveal an unclear agreement that needs human clarification.
Several tasks concerning the same recurring problem may share a cause but need different inputs. Recurring customer reports explains preserving that context. Do not connect every task into a chain merely because their titles are similar. The actual required result, not thematic proximity, determines whether one should wait for another.
Choose the relationship meaning and describe its condition manually
In Meetlead Projects, tasks can have directed blocking relationships, ordinary connections and duplicate relations. A connection displays the appropriate inverse relation on the other side. You need an account, website, permissions, active Projects installation and a plan with access. The team selects the meaning based on the actual work, not an assumed automatic classification.
The description or comment should explain what unblocks work. A relationship is not an automatic schedule, calculated dates or critical-path analysis. Do not promise that the tool inspects the document or changes a deadline after a status update. Responsible people check input readiness and its effect on subsequent work through the team’s process.
Do not use duplicate as a substitute for blocking. Two cards representing the same work need context organisation rather than waiting for one to supply an output to the other. Otherwise the team may perform the same scope twice or retain an unnecessary blocker. Select the relation that matches the actual connection and make the remaining work clear.
Check six questions before recording a blocker
- Does the next step actually require the predecessor’s result?
- Can the direction be read correctly from both sides?
- Does unblocking identify a particular version or decision?
- Can part of the work proceed independently?
- Is the apparent dependency actually a duplicate?
- Was input readiness checked after predecessor completion?
When the blocker is client material, a “waiting” title is insufficient. The next guide covers missing client materials with a particular request scope and restart condition. That record should explain what the client can provide rather than merely showing that a dependent task remains idle.
When direction or readiness is unclear
Are two tasks in one project dependent? Not merely because they share a project. Check the required input.
If both can be completed without the other’s result, an ordinary relationship may describe them better. Avoid imposing a sequence that blocks work without a concrete reason.
Does predecessor completion always unblock work? Not automatically. Compare its result with the recorded condition for the next stage.
A missing version or decision may still block the step despite another portion being complete. The relationship concerns the required result rather than the colour of the predecessor’s card.
Should the tool calculate a new date? Here the team reviews sequence manually. The relation documents a connection rather than delivering a schedule calculation.
Establish the input change’s effect with the responsible person before promising a customer date. A visible dependency is useful evidence for that conversation, not a date commitment itself.
Atlassian explains dependencies as relationships affecting work sequence. Our copy-and-publication example uses manual checks: project dependencies.
