Should a Business App Block Work Until Another Task Is Finished?

Use a hard prerequisite only when starting or completing the next step really must be prevented. For ordinary coordination, a visible “waiting for” relationship may be enough. Before commissioning a workflow app, decide which kind of dependency each process needs, what counts as satisfying it and who can handle exceptions.

A line connecting two tasks does not, by itself, specify any of those rules. This guide describes requirements to agree with a developer, not guarantees of a particular task-management product.

Name the blocked action

“Installation depends on inspection” is too vague for a specification. Can the team schedule installation while inspection is pending? Prepare materials? Start the work? Mark it complete?

Choose the actual action the app should prevent, rather than locking the entire record. A hypothetical repair business might allow preparation while requiring an approved inspection before work starts. That example describes a software choice, not safety advice or a substitute for professional approval procedures.

For a softer relationship, show the unfinished prerequisite and allow the user to proceed. If you want a warning or a recorded explanation, say so explicitly. Do not label a warning as a guaranteed control.

Define what clears the dependency

A prerequisite might mean a task is marked complete, a result is approved or a required document has passed review. These are different events. Agree which stored fact makes the dependent action available.

When several prerequisites exist, decide whether all must be satisfied or whether one of several alternatives is enough. Also define cancellation: canceling an inspection should not silently mean it passed. A canceled prerequisite may need replacement, an explicit waiver or continued blocking, depending on the agreed process.

As a product example, Asana's official API documents separate operations for setting task dependencies and retrieving a task's dependencies. That supports describing a relationship between tasks. Those endpoint descriptions are not evidence that a particular business action is prevented or that an approval is complete. Ask for the actual enforcement behaviour separately.

Prevent loops that leave nobody able to proceed

Require the app to reject a dependency on the task itself and to detect circular chains if your workflow requires prerequisites to finish first. Otherwise one task can wait for another that ultimately waits for the first.

Do not rely only on a screen check. Ask the developer to demonstrate that simultaneous edits cannot leave a prohibited loop in the saved workflow. If the design deliberately allows nonblocking related-task links, distinguish those links from enforced prerequisites.

The loop checks here are recommendations for the custom workflow, not claims about Asana's implementation.

Decide what reopening a prerequisite means

If a completed prerequisite is reopened, should unfinished downstream work become blocked again? What if downstream work has already finished?

A useful default to discuss is to reassess actions that have not happened yet, while flagging already completed work for review instead of silently reversing it. The correct policy depends on the process. Some changes may require an immediate operational response, which cannot be settled by a generic task status.

Show the reason for a renewed block and assign responsibility for resolving it. “Blocked” without an identifiable prerequisite or owner leaves staff unable to act.

Make exceptions deliberate

If an override is permitted, define who may use it, which prerequisite it bypasses and what explanation is retained. Separate a one-time waiver from deleting the relationship for every future decision. An override should not falsify the original task's result.

Keep restricted prerequisite details protected. A person may need to know that an approval is missing without receiving access to the underlying confidential record. Agree what the blocked-action message is allowed to reveal.

Ask for a small demonstration

Record these cases in your acceptance criteria:

• Preparation remains available while the specified action is blocked.
• Completing the correct prerequisite enables only the intended action.
• Multiple prerequisites follow the agreed all-or-alternative rule.
• Cancellation does not impersonate successful completion.
• A self-dependency and an indirect loop are rejected where prohibited.
• Reopening a prerequisite has the agreed effect on unfinished and completed work.
• An authorised exception is explained without rewriting the original outcome.

When discussing a workflow app, bring one real process stripped of confidential data and identify its precise stop points. A short chain with clear rules is a stronger starting point than a diagram full of unexplained arrows.

Sources and scope

Asana, setting dependencies: https://developers.asana.com/reference/adddependenciesfortask

Asana, retrieving dependencies: https://developers.asana.com/reference/getdependenciesfortask

Only the documented relationship operations are attributed to Asana. Blocking, loop detection, reopening and exception handling above are proposed requirements to implement and test for the commissioned system.