Build the foundation of your workflow

Before building a workflow in Asana, it’s important to set the foundation so that your workflow functions properly. This article is part 2 of a 3 part series. To check out the first article in the series, please click here. 

Building blocks of a workflow

Organization

Organizations connect all the employees at your company using Asana in a single space based on your company's shared email domain.

Teams

Within the Organization, you and your colleagues split into teams to collaborate on your projects and tasks. Every user in your organization is part of at least one team but can be part of multiple teams.

Projects

Projects allow you to organize all of the tasks related to a specific initiative, goal, or big piece of work. Within projects, you’ll use sections to organize your tasks.

Tasks

Tasks are the basic unit of action in Asana.

Subtasks

Use subtasks to break up the work of a task into smaller parts or to help divide up the work among multiple people.

Comments

Comment on a task to ask questions, provide extra information, or offer insights.

Workflow set up decisions

Next, to make sure your workflow functions properly, you’ll need to make a set of key decisions.

Decision 1: Project or Task

The most common question teams ask is whether or not they house their workflow within a project or a task.

We recommend starting with a project to house your overall workflow.

A project gives you a central place to coordinate with stakeholders. Add tasks and subtasks to represent actionable work. Tasks that are too vague, like "Promotion" are difficult to execute. Break work down so that tasks are actionable.

Decision 2: How to use sections

When deciding how to use project sections, it’s helpful to understand the two main ways that work moves through a workflow: in sequences and stages.

Sequences

Sequences are like checklists -- work gets completed in a specific order, building up to a final deliverable. Planning an event or onboarding a new hire are great examples of sequenced workflows. In these cases, consider setting up your project in List view and use sections to group tasks by category or time frame.

Stage

Stages are like pipelines -- a single deliverable moves through a series of stages to completion. Request processes or product development pipelines are great examples of staged workflows. In these cases, consider setting up your project in Board view and use sections to represent each stage. Your tasks represent each deliverable, and you move them from one section to the next as they move through each stage.

Decision 3: Which custom fields to add

You should think about custom fields early. The way you organize, automate and report on your workflow depends on which fields you’ve added.

Organize

How do you need to organize tasks in your workflow? Create fields for specific categories.

Automate

How do you want to automate your workflow? You can create custom rules based on the fields you add.

Report

What do you need to report on in your workflow? Charts available to you in the project dashboard depend on your custom fields.

Decision 4: When to use subtasks

Sometimes a single task or deliverable needs to be broken out into smaller, sequential steps. Use subtasks in these instances.

Be careful about building entire workflows out of only tasks and subtasks. This can cause trouble down the line when you want to add automation, use Timeline view, or report on work.

Common uses for subtasks

If the top level task is a request, consider using subtasks to capture the follow-up steps.

When you need multiple people to approve work on a top level task, add approval requests as subtasks.

Some workflows have actions that only happen on certain conditions. For example, a team that manages requests may have certain conditions where they need more information before moving the request into progress. In those cases, use the rule to add subtasks when a task moves into that particular stage.

Did you know you can add sections to sub-tasks? Use the keyboard shortcut "tab + N"

As a general rule of thumb, if you’re adding more than 10 subtasks, you might consider building a project with tasks instead.

Decision 5: One project or multiple?

Sometimes a workflow is large enough that it could span multiple projects.

Use multiple projects when:

Your workflow intersects with another team who already uses their own project. For example, a team may track their story publications in one project while another team may need to discuss that same item in an upcoming meeting. So the teams add the relevant tasks to both projects.

The phases of your workflow involve such a high volume of tasks, that it would create too much noise to have it all exist in one project. For example, a team may use one project to manage a request inbox but they receive a high volume. So they create a separate project to take action on the requests once they’re in progress. They use custom rules to automate this process.

Decision 6: How to set up project permissions?

Depending on how you set up your permissions will affect how your workflow functions. You can give project members either edit or comment only permissions. Comment-only permissions allow teammates to view or comment on projects without giving them access to edit them.

Comment-only permissions are only available for teams and Organizations on Asana Starter, Advanced, Enterprise, and Enterprise+ tiers, as well as legacy tiers Premium, Business, and Legacy Enterprise.

Most workflows will require you to give project members edit permissions so they can take action on their own tasks. We recommend comment only permissions when: A project needs to be publicly viewable by many stakeholders who are not responsible for any of the tasks. Projects have sensitive information and you need to prevent accidental or unnecessary changes.

Go here to learn more about permissions in depth.

Once you’ve set the foundation of your workflow, it’s time to add movement. Check out the next article in this series