Why Standard Task Management Was Not Enough
Asana is an excellent project management platform. It provides tasks, forms, custom fields, approvals, rules, and automation features that cover a wide range of use cases. However, challenges arise when business processes span multiple departments and contain decision points, rework loops, approvals, and mandatory checks.
Consider a typical Engineering Change Request process in a manufacturing environment.
A request may initially be submitted by Production, reviewed by Engineering, validated by Quality, processed by Purchasing, and finally implemented by Production. In practice, however, the process is often far more complex. Quality may reject a design and return it to Engineering. Purchasing may not be required for certain changes. Additional approvals may be required depending on cost, risk, or customer impact.
At this point, many organizations discover a limitation: Asana is designed for project management, not as a full Business Process Management (BPM) system. It does not provide a native workflow engine with predefined states and allowed transitions.
The challenge therefore becomes simple:
How can we ensure that a task is always forwarded to the correct next department?
The Traditional Approach
The most common solution is to create a status field containing values such as:
- New
- In Progress
- Review
- Approved
- Completed
This works well as long as the workflow is linear.
However, as soon as departments appear multiple times in the process, this approach becomes difficult to maintain.
Imagine the following process:
Production → Engineering → Quality → Engineering → Purchasing
When the task arrives in Engineering for the second time, how does the system know whether it should proceed to Purchasing or return to Quality again?
A simple status field does not provide enough information to determine the next valid step.
A Different Approach
Instead of storing where a task currently is, I decided to store where the task is allowed to go next.
This is achieved by using Asana Task Types as routing instructions.
Examples:
- Production → Engineering
- Engineering → Quality
- Quality → Purchasing
- Purchasing → Production
Each task type represents a specific departmental transition.
In other words, task types are no longer used to describe what a task is. Instead, they describe where the task should go next.
This transforms task types into a lightweight routing engine.
Why This Works
Whenever a department completes its work, users do not choose the next department manually.
Instead, they select the predefined task type that represents the next process transition.
For example, when Engineering has completed its work, the task type may already be set to “Engineering → Quality”.
A rule detects this value and automatically:
- Moves the task to the Quality section
- Assigns the appropriate users
- Updates phase information if required
- Prepares the next routing step
Once the task reaches Quality, another task type such as “Quality → Purchasing” is automatically assigned.
This means that every task always knows what the next valid destination is.
The Three Layers of the Architecture
The solution is built around three separate layers.
Layer 1: Sections
Sections represent the department that is currently responsible for the task.
Typical sections may include:
- Production
- Engineering
- Quality
- Purchasing
At any given time, a task belongs to exactly one section.
This provides clear ownership and visibility.
Layer 2: Task Types
Task types represent the next allowed process transition.
Examples include:
- Production → Engineering
- Engineering → Quality
- Quality → Engineering
- Quality → Purchasing
- Purchasing → Completed
This is the core concept of the solution.
The current section answers the question:
“Who is responsible right now?”
The task type answers the question:
“Where is this task supposed to go next?”
Layer 3: Workflow Phases
For more complex scenarios, a custom field called “Phase” can be introduced.
Examples:
- 01 - Initial Assessment - Production
- 02 - Technical Evaluation - Engineering
- 03 - Quality Validation - Quality
- 04 - Procurement Preparation - Purchasing
The purpose of the phase field is to distinguish between different situations in which the same department may appear multiple times.
Without this additional information, automation can become ambiguous in highly complex workflows.
Example Use Case: Engineering Change Request
To illustrate the concept, let’s follow a realistic engineering change request.
A production issue is identified and submitted through an Asana form.
The request enters the Production section.
Based on the form information, automation assigns the task type:
“Production → Engineering”
Once the Production team completes its initial assessment, a rule automatically routes the task to Engineering.
After reviewing the request, Engineering determines that Quality must validate the proposed solution.
The task type changes to:
“Engineering → Quality”
The request is forwarded automatically.
During validation, Quality discovers a potential issue and requires adjustments.
The task type becomes:
“Quality → Engineering”
The task returns to Engineering.
After revisions are completed, Engineering forwards the task back to Quality.
This time the solution passes validation.
Quality assigns the task type:
“Quality → Purchasing”
Purchasing evaluates supplier impact and procurement requirements before routing the task to its final implementation stage.
Throughout the entire process, users do not need to determine where the task should be routed. The routing logic is stored directly within the task itself.
Handling Decision Points
Many business processes contain approval gates or branching logic.
For example, Quality may need to decide whether a change is approved or rejected.
Instead of relying on comments or manual communication, decisions are stored in custom fields.
Examples include:
- Approval Status
- Review Result
- Risk Level
- Classification
Automation rules evaluate these values and select the appropriate next routing task type.
As a result, the workflow can branch automatically based on business decisions.
Using Subtasks as Mandatory Checklists
Many departments are required to perform a standard set of activities before forwarding a task.
Examples may include:
- Complete technical review
- Upload documentation
- Perform risk assessment
- Verify customer requirements
Whenever a task enters a new phase, automation can create these subtasks automatically.
Additional rules then verify whether all subtasks have been completed.
If they are not completed:
- The task remains in the current department
- The routing action is reversed
- An automated reminder can be generated
This effectively creates a process gate without requiring specialized workflow software.
Is This a Workaround?
Partially.
This architecture is not the standard way most organizations configure Asana.
However, it is not a workaround in the usual sense either.
A workaround typically compensates for a missing feature in an ad-hoc manner.
This approach is better described as an architectural pattern.
It uses standard Asana functionality—task types, custom fields, forms, sections, and rules—to create behavior that resembles a workflow engine.
The result is a highly structured process environment without requiring additional software.
Benefits of the Approach
The solution offers several significant advantages.
Every task knows its next valid destination.
Routing decisions become standardized and auditable.
Users no longer need to understand the entire workflow to perform their work correctly.
The architecture supports:
- Multiple departments
- Approval processes
- Rework loops
- Alternative process paths
- Mandatory checklists
- Automated notifications
Most importantly, the entire solution remains inside Asana.
There is no need for a separate BPM platform, workflow tool, or custom development effort.
Conclusion
The key idea behind this approach is simple:
Task types do not describe what a task is. They describe where a task is allowed to go next.
By turning task types into routing instructions, Asana can be used for far more than traditional project management.
Combined with sections, workflow phases, custom fields, and automation rules, this architecture enables organizations to manage sophisticated cross-functional processes that would traditionally require dedicated workflow software.
For simple workflows, the approach is unnecessary.
For complex business processes involving multiple departments, decision points, approvals, and rework cycles, it can transform Asana into a surprisingly capable workflow engine while remaining fully within the platform’s standard functionality.
