Asana
Asana is a work management tool that you can start using right away just by looking at it, helping you and your team create tasks, assign work, and track progress all in one place. It features a Kanban board, timeline, checklists, due-date reminders, process automation, and clear reporting — making it easier to remember tasks, reduce chat chaos, and work faster.
- Project management
- Workflows and automation
- Goals and reporting
- Resource management
- Admin and security
- Integrations
Asana — Project management
Based on Asana’s official “Capabilities” navigation (Project management) and core object model (Work Graph / object hierarchy).
Quick scan
- Outcome: you can model work as tasks inside projects, then pick the right view (list/board/timeline/calendar).
- Fast win: create one project, add 10 tasks, assign owners + due dates, and review in My tasks.
- Good default: keep tasks small + named as actions; keep projects for shared scope and visibility.
- Reading time: ~12–15 minutes.
Core terms referenced: tasks, projects, sections, subtasks, custom fields, status updates, views.
Purpose, who it’s for, and where it lives
Project management in Asana is about making work visible: who owns it, what “done” means, and when it’s due. You’ll use it when multiple people need one shared place to track progress instead of scattered messages.
- Who: individuals managing personal work, and teams coordinating shared deliverables.
- When to use: repeatable processes, launches, campaigns, sprints, and any work with dependencies.
- Where in navigation: your work shows up through Projects, My tasks, Inbox, and Home (all listed under Project management features).
- Related tabs: Goals and reporting (for outcomes), Workflows and automation (for intake + rules), Admin and security (for access).
Mental model (end-to-end flow)
Think of Asana as a Work Graph: tasks connect to projects, and projects connect to teams/workspaces. A task can belong to zero, one, or multiple projects (multi-homing), so visibility can scale without duplicating work.
- Capture a piece of work as a task (clear action + owner).
- Organize tasks into a project (shared scope), then into sections (stages/categories).
- Plan timing with due dates and the project view that fits (list/board/timeline/calendar).
- Collaborate via comments, followers/collaborators, and status updates.
- Review in My tasks (personal queue) and dashboards/status (team health).
Objects & terms you must know
These are the building blocks you’ll keep touching. If you get these right, everything else becomes easier.
- Task: basic unit of action with one assignee, name, notes, followers/collaborators, comments, and more.
- Project: a collection of tasks; can be viewed as list/board/timeline/calendar (and similar layouts).
- Section: groups tasks inside a project (stages, priorities, categories).
- Subtask: a task whose parent is another task; does not automatically inherit the parent task’s projects.
- Custom field: structured labels/values added to tasks (can be organization-wide or project-specific).
- My tasks: your personal “what I owe next” view; great for daily prioritization.
- Inbox: updates about work you follow/participate in; filter to what matters.
Core jobs-to-be-done (what you’ll do most)
If you can do the jobs below smoothly, you’re productive in Asana. These map directly to Asana’s core project management capabilities.
- Break down work: turn a vague request into 5–20 tasks with clear owners and due dates.
- Make progress visible: use sections to represent stages, and update task status (done / in progress via fields or workflow).
- Keep one source of truth: store decisions in task comments and attach key files to the relevant tasks.
- Align daily execution: use My tasks to plan today, this week, and overdue items.
- Share project health: publish a short status update with what changed + next risks.
- Choose the right view: list for detailed tracking, board for stage flow, timeline for sequencing, calendar for date-driven work.
Happy path workflow #1 — Build a simple project from scratch
Use this when you’re starting a new initiative and want a clean baseline. The goal is a project anyone can understand in 60 seconds.
- Create a project with a clear name (noun + outcome), e.g., “Website refresh — Launch”.
- Add sections for stages (Backlog → Doing → Review → Done) or categories (Design/Copy/Dev).
- Brain-dump 10–30 tasks (each task name starts with a verb: “Draft…”, “Review…”, “Publish…”).
- Assign an owner to each task (one person per task).
- Add due dates for tasks that unblock others (don’t date everything on day one).
- If needed, add subtasks for checklists that belong to a single task.
- Add 1–3 custom fields only if they answer a real question (e.g., Priority, Effort).
- Switch to the best view (list/board/timeline/calendar) for how your team thinks.
Expected outcome: a project with clear stages, actionable tasks, assigned owners, and enough dates to drive the next week of work.
Happy path workflow #2 — Run your day from My tasks
Use this daily. The goal is to make your personal queue realistic and make sure nothing important is “invisible”.
- Open My tasks and scan Overdue first.
- For each overdue item: either complete it, re-scope it, or re-date it (don’t leave it stale).
- Review tasks Due today; pick the top 3 outcomes you will finish.
- Drag/reorder or group items into sections you control (e.g., Today / This week / Waiting).
- Open each priority task and confirm: owner (you), due date, and the next action in the description.
- Add a comment or @mention if you’re blocked; assign a follow-up task if needed.
- Batch small tasks (≤5 minutes) and finish them in one focused block.
- End of day: mark done, and push forward what didn’t happen (with a new plan/date).
Expected outcome: your My tasks is a trustworthy list you can execute from without constantly context-switching.
Decision points (pick the right structure)
These A/B choices prevent most early “Asana feels messy” problems.
| Situation | Choose A | Choose B |
|---|---|---|
| Work item is actionable and owned by one person | Create a task | Don’t create a project just for one action |
| Many related tasks need shared visibility | Create a project | Don’t keep them only in My tasks |
| You need stages like “In review / Done” | Use sections or a board-style flow | Don’t encode stages in task names |
| One task belongs in multiple contexts | Use multi-homing (same task in multiple projects) | Don’t duplicate tasks and lose history |
| You want consistent labels across many projects | Use a shared custom field library (if available) | Don’t create slightly-different fields per project |
Guardrails (do/don’t, pitfalls, common mistakes)
Most trouble comes from unclear naming, missing owners, and too much structure too early. Use these guardrails to stay lightweight while still consistent.
Do / Don’t
- Do: name tasks as actions (“Send…”, “Draft…”, “Confirm…”).
- Do: keep one assignee per task; collaborate via followers/comments.
- Do: use sections to reflect how work moves (stages or categories).
- Don’t: create custom fields “because you can”; add only when they drive decisions.
- Don’t: duplicate tasks across projects; prefer multi-homing.
- Don’t: make deep subtask trees; keep breakdown shallow and readable.
Common mistakes (and how to avoid)
- No owner: every task needs one responsible person; otherwise it’s just a note.
- Everything due today: date only what truly needs a deadline; use sections/priorities for the rest.
- Projects as folders: projects work best as living hubs (tasks + updates), not static storage.
- Stage in title: don’t prefix tasks with “DONE/INPROG”; use sections/fields/views.
- Over-automation early: build a stable workflow first; automate once patterns repeat.
Permissions & roles: Not applicable for this tab (see Admin and security for access controls). Data & integrations: Not applicable for this tab (see Integrations and Workflows and automation).
What good looks like + checklists + practice lab
A “good” setup is one where a new teammate can answer: what’s the goal, what’s next, and who owns it—without asking you. Use the checks below to validate your structure.
What good looks like
- Tasks have clear verbs and one owner.
- Sections reflect a real workflow or real categories.
- Only a few fields exist—and they’re used in reviews.
- Project view matches how the team plans (list/board/timeline/calendar).
- Status updates summarize progress + risks (not a wall of text).
Pre-check (before you invite others)
- Project has a one-line purpose in the description/brief.
- 3–6 sections max (start simple).
- Top 10 tasks are assigned.
- At least 3 tasks have meaningful due dates.
- One status update template exists (What changed / Next / Risks).
Post-check (after 1 week)
- No more than 20% tasks are unassigned.
- Overdue tasks are re-planned, not ignored.
- Sections are still meaningful (not “Misc”).
- Fields are filled consistently (or removed).
- Team can run a standup by scanning the project view.
Practice lab (10–15 min)
Goal: build one small project you can actually use this week.
- Create a project: “Personal weekly planning”.
- Add sections: Backlog, This week, Today, Done.
- Add 12 tasks; assign yourself; add due dates to at least 4.
- Add one custom field “Priority” only if you’ll use it daily.
- Open My tasks and make sure the “Today” tasks are visible and realistic.
Verify you did it right: you can finish your day by only checking My tasks + your project, and nothing feels “lost”.
Official docs links
- Project management (capability overview)
- Projects — sections, layouts, and switching views
- Custom fields — labels you can sort/filter/report on
- Asana object hierarchy (Work Graph model)
Asana — Workflows and automation
Based on Asana’s official “Workflows and automation” capability (Forms, Rules, Bundles, Templates).
Quick scan
- Outcome: your team captures requests consistently and moves work forward with less manual busywork.
- Fast win: build one form that creates tasks into a project, then add one simple rule.
- Good default: standardize with templates first, then automate repeatable actions with rules.
- Reading time: ~12–15 minutes.
Core terms referenced: forms (intake), rules (automation), templates (standardization), bundles (apply process at scale).
Purpose, who it’s for, and where it lives
Workflows and automation help you reduce “process tax”: missing info, inconsistent steps, and repetitive admin work. You’ll use it when your team repeats the same flow every week or handles lots of inbound requests.
- Who: team leads, ops, project owners, and anyone who receives requests from others.
- When to use: intake (forms), routing and triage (rules), and consistent delivery (templates/bundles).
- Where in navigation: Workflows and automation capability includes Forms, Rules, Bundles, and Templates.
- Related tabs: Project management (where the work lands), Integrations (connect tools), Admin and security (control who can do what).
Mental model (intake → standardize → automate)
A good workflow has three layers: capture consistent inputs, run a consistent process, then automate the repeatable steps. In Asana, this usually means form submissions create tasks, templates define structure, and rules do the routing and updates.
- Capture: use a form so requests start with the right details (no back-and-forth).
- Standardize: use templates (and bundles if applicable) so every project/task follows the same pattern.
- Automate: add rules to move tasks, assign owners, set fields, or trigger follow-ups.
- Measure: track outcomes via dashboards/goals once the flow is stable.
Objects & terms you must know
These terms keep workflow conversations precise. They also help you decide what to automate vs what to leave manual.
- Form: standardized intake; can be kept private to your company or shared publicly on the web (depending on settings).
- Rule: automation that runs when something changes (e.g., a field value, a section move).
- Template: reusable project or task structure so teams start from the same baseline.
- Bundle: a way to create/apply/update processes across projects at scale.
- Field-driven automation: rules often depend on custom fields (like Priority, Type, Region).
- Destination project: where form-created tasks are added and tracked.
Core jobs-to-be-done
These are the most common workflow problems Asana features are designed to solve.
- Build an intake funnel: collect requests with required fields and attach files at submission time.
- Triage quickly: route requests to the right section/owner based on type or priority.
- Enforce consistency: start projects from templates rather than reinventing structure.
- Reduce manual updates: auto-assign, auto-tag, and auto-move tasks when conditions match.
- Scale best practices: apply the same process across many projects (bundles).
Happy path workflow #1 — Create a request intake form
Use this when people keep sending you half-complete requests. The goal is: every request lands as a clear task, ready for triage.
- Create (or pick) a destination project where all requests will live.
- Add sections such as New, Needs info, Accepted, Done.
- Create a form tied to the destination project.
- Add questions that map to task fields (request type, due date, priority).
- Enable attachments in the form if requesters must provide files.
- Set form permissions: internal-only (company) or shareable link (web), based on your use case.
- Submit 2–3 test requests yourself to see how tasks appear in the project.
- Adjust questions until tasks arrive “ready to triage”.
Expected outcome: requests consistently arrive as tasks with the minimum information your team needs to start work.
Happy path workflow #2 — Add one simple rule that saves time
Start with one rule that removes a daily annoyance. The goal is to automate a repeatable step without making the system confusing.
- Choose a simple trigger: when a task is added or when a field changes.
- Choose one action: assign, move to section, or set a field value.
- Example: if “Request type = Design”, then assign to the design owner and move to “New”.
- Create the rule and run 3–5 test tasks through it.
- Make the rule’s logic visible: document it briefly in the project description/notes.
- Watch for one week: does it ever assign/move incorrectly?
- Only then add a second rule (avoid stacking many rules at once).
Expected outcome: tasks get routed consistently with fewer manual moves and less back-and-forth.
Decision points (what to automate vs keep human)
Automation should remove repetition, not remove judgment. Use this table to decide.
| Situation | Choose A | Choose B |
|---|---|---|
| Requester often forgets key details | Form with required questions | Don’t rely on free-text messages |
| Routing is predictable (based on type/priority) | Rule to assign/move/set fields | Don’t make someone manually triage every time |
| Work varies a lot case-by-case | Keep triage manual (human judgment) | Don’t over-automate and create wrong work |
| Every project should start the same way | Template (and bundle if scaling) | Don’t rebuild structure from memory |
| Multiple teams need the same process | Bundles (apply/update across projects) | Don’t copy-paste and drift over time |
Guardrails (do/don’t, pitfalls, common mistakes)
Automation should make the “happy path” automatic, and the “edge cases” obvious. Keep rules simple and visible.
Do / Don’t
- Do: start with 1–3 rules per project, then grow slowly.
- Do: base rules on stable signals (a field value) rather than fragile text.
- Do: document your workflow in one short place (project notes/description).
- Don’t: automate decisions that require context (risk, quality, stakeholder alignment).
- Don’t: create multiple overlapping rules that fight each other.
- Don’t: ship a form without testing how tasks appear in the destination project.
Common mistakes (and how to avoid)
- Form too long: ask only what you truly need to start; add optional questions later.
- No triage stage: always have a “New” section so intake doesn’t mix with in-progress work.
- Hidden logic: if rules exist, write a 5-line “How we triage” note in the project.
- Too many templates: prefer one good template per use case, not dozens of variants.
- Process drift: if scaling, use bundles so updates propagate instead of manual copying.
Permissions & roles: Partly applicable (forms can be private to company or shareable on the web). For org-wide controls, see Admin and security. Data & integrations: See Integrations for connecting other tools.
What good looks like + checklists + practice lab
A workflow is “good” when it produces consistent, triage-ready tasks and the team trusts it. Use the checklists to keep the system simple and maintainable.
What good looks like
- Most requests arrive with required info and attachments.
- Routing is consistent and predictable.
- Rules are few, stable, and easy to explain.
- Templates reflect how the team actually works.
- Automation reduces manual moves without hiding important decisions.
Pre-check
- Destination project has clear intake sections (New / Needs info / Accepted).
- Form asks for priority and due date (or explains why it doesn’t).
- At least one test request was run end-to-end.
- One simple rule exists (assign OR move OR set field).
- Team knows where to submit requests (single link/source of truth).
Post-check (after 2 weeks)
- Fewer “missing info” comments than before.
- Rules rarely mis-route tasks; exceptions are documented.
- Template usage is high (people actually start from it).
- Process changes are versioned/communicated (no surprises).
- New teammates can follow the workflow without 1:1 coaching.
Practice lab (10–15 min)
Goal: create a mini “work request” system for one team.
- Create a project: “Team requests (intake)”.
- Add sections: New, Needs info, Accepted, Done.
- Create a form with: Request type, Due date, Priority, Attachment upload.
- Create one rule: if Priority = High, move to New and assign to a triage owner.
- Submit 3 fake requests and confirm the routing is correct.
Verify you did it right: each submission becomes a task that lands in the right section with the right owner (or at least is ready for triage).
Official docs links
- Workflows and automation (capability overview) — Forms, Rules, Bundles, Templates
- Forms — standardized intake and permission options
- Rules — automate routine actions
- Templates & Bundles — standardize and scale processes
Asana — Goals and reporting
Based on Asana’s official “Goals and reporting” capability (Goals, Portfolios, Reporting dashboards) and the Goals object model.
Quick scan
- Outcome: connect daily work (projects/tasks) to measurable goals and review progress with dashboards.
- Fast win: define 1 goal, connect 1 project, and set a weekly check-in ritual.
- Good default: fewer goals, clearer owners, measurable progress signals.
- Reading time: ~12–15 minutes.
Core terms referenced: goal, supporting work, portfolio, dashboards, status summaries.
Purpose, who it’s for, and where it lives
Goals and reporting answer two questions: “Are we winning?” and “What work is driving the outcome?” This is for leaders and teams who want fewer status meetings and more shared clarity.
- Who: team leads, managers, project owners, and stakeholders who need visibility.
- When to use: quarterly goals, cross-team initiatives, portfolio/program oversight, weekly business reviews.
- Where in navigation: Goals and reporting capability includes Goals, Portfolios, and Reporting dashboards.
- Related tabs: Project management (execution), Resource management (capacity), Admin and security (access governance).
Mental model (connect work → measure → review)
A goal is an object used to drive measurable results. In practice: define a goal, connect the projects or sub-goals that support it, then review progress on a cadence using dashboards and portfolio-level summaries.
- Define: goal name, owner, time period, and how success is measured.
- Connect: link supporting projects/portfolios/sub-goals so the goal reflects real work.
- Track: update progress (manually or via connected work, depending on setup).
- Review: use dashboards for signals and publish short status summaries for stakeholders.
- Act: create/adjust tasks to address risks shown by the data.
Objects & terms you must know
Keep these definitions tight so your reporting stays meaningful.
- Goal: an object in the goal-tracking system; can live at workspace, team, or individual level.
- Goal owner: accountable person who updates progress and drives follow-through.
- Supporting work: projects/portfolios/tasks/sub-goals that contribute to the goal.
- Portfolio: a collection of projects (or other portfolios) for high-level oversight.
- Reporting dashboard: real-time charts and insights built from projects, portfolios, goals, or tasks.
- Status summary: a concise narrative update for stakeholders (what changed, risks, next).
Core jobs-to-be-done
These jobs create a tight loop between strategy and execution.
- Write goals that can be measured: define a metric or clear completion criteria.
- Connect goals to work: link projects so progress reflects reality, not feelings.
- Maintain stakeholder clarity: publish short, regular status summaries.
- Spot blockers early: use dashboards to see trends and bottlenecks.
- Run lightweight reviews: weekly check-in for teams; monthly/quarterly for leadership.
Happy path workflow #1 — Set up one goal with clear measurement
Use this to turn a fuzzy objective into something you can actually track week to week.
- Create a goal with a simple name: “Increase onboarding completion”.
- Assign a single goal owner (one accountable person).
- Set the time period (e.g., this quarter) so reviews have a rhythm.
- Choose how you will measure success (a metric or completion definition).
- List 2–4 supporting projects that will move the metric.
- Connect those projects to the goal (so the goal references real work).
- Schedule a weekly 10-minute update where the owner refreshes progress.
- At each update, create a task for the next corrective action if progress is off track.
Expected outcome: one goal that has an owner, a measurement, connected work, and a regular update cadence.
Happy path workflow #2 — Build a simple reporting dashboard
Use this when stakeholders keep asking “Where are we at?” The goal is a single place to see progress signals without manual slide decks.
- Pick a scope: one project, one portfolio, or a goal area.
- Create a reporting dashboard for that scope.
- Add 2–4 charts that answer real questions (e.g., work by status, by priority, by assignee).
- Define what “healthy” looks like (e.g., overdue tasks below a threshold).
- Share the dashboard with the stakeholder group (read-only if needed).
- Pair the dashboard with a weekly status summary (3–5 bullets).
- When the dashboard shows a risk, create a task: owner + due date + next action.
- Review monthly: remove charts no one uses; keep only decision-driving signals.
Expected outcome: a lightweight dashboard + update ritual that reduces status meetings and drives action.
Decision points (make reporting meaningful)
Reporting is only as good as the inputs. These decisions keep the signal clean.
| Situation | Choose A | Choose B |
|---|---|---|
| You can measure progress with a metric | Use a measurable goal | Don’t rely only on subjective status |
| Many projects roll up to one initiative | Use a portfolio for oversight | Don’t keep progress scattered across projects |
| Stakeholders need real-time visibility | Use dashboards | Don’t rebuild weekly slide decks from scratch |
| Work is too noisy to summarize daily | Set a cadence (weekly/monthly) | Don’t spam updates; keep them regular and useful |
| Charts don’t drive decisions | Remove them | Don’t keep “vanity charts” |
Guardrails (do/don’t, pitfalls, common mistakes)
Reporting systems fail when goals are vague, ownership is unclear, or the underlying work isn’t maintained. Keep your system small and honest.
Do / Don’t
- Do: keep goals few and high-impact.
- Do: ensure each goal has exactly one owner.
- Do: connect goals to projects that actually move the metric.
- Don’t: treat goals as a list of wishes without measurable outcomes.
- Don’t: overload dashboards with every possible chart.
- Don’t: publish status updates without naming risks and next actions.
Common mistakes (and how to avoid)
- Too many goals: reduce until teams can actually review them regularly.
- No measurement: define a metric or completion definition before launching the goal.
- Disconnected work: link projects so people see what’s driving progress.
- Stale dashboards: review monthly; keep only charts that drive decisions.
- Status as storytelling: always include “next action” tasks with owners and dates.
Permissions & roles: Not applicable for this tab (see Admin and security). Data & integrations: Partly applicable (some goals/reporting can connect to other systems); see Integrations.
What good looks like + checklists + practice lab
A good goals/reporting setup creates clarity and action—not bureaucracy. Use the checklists to validate that your system is lightweight and trustworthy.
What good looks like
- Every goal has a measurable definition.
- Progress updates happen on a predictable cadence.
- Connected projects clearly support the goal.
- Dashboards show a small set of decision-driving signals.
- Risks trigger concrete tasks (owner + date), not vague concern.
Pre-check
- Goal owner and time period are set.
- Measurement is defined and agreed.
- At least one supporting project is connected.
- One dashboard exists for the initiative.
- Stakeholders know where to look (one link).
Post-check (after 1 month)
- Updates are not skipped; cadence is stable.
- Dashboards are actually viewed/used.
- Goal discussions lead to task-level actions.
- Projects stay maintained (owners, dates, statuses).
- Stakeholders ask fewer “Where are we?” questions.
Practice lab (10–15 min)
Goal: set up one measurable goal and one basic dashboard.
- Create a goal for the next 30 days (pick a real metric or a clear completion definition).
- Pick one existing project that supports the goal and link it.
- Create a dashboard with 2 charts: work by status, and overdue tasks.
- Write a 5-bullet status update: What changed / What’s next / Risks.
- Create one follow-up task from the biggest risk.
Verify you did it right: someone else can open the goal and immediately see (a) what success means and (b) which work is driving it.
Official docs links
- Goals and reporting (capability overview)
- Goals — connect work and track progress
- Portfolios — monitor multiple projects
- Reporting dashboards — real-time charts and insights
- Object hierarchy (Goals + Portfolios definitions)
Asana — Resource management
Based on Asana’s official “Resource management” capability (Capacity planning, Workload, Time tracking).
Quick scan
- Outcome: avoid overloading people, plan realistic timelines, and track time/capacity when needed.
- Fast win: identify the top 3 overloaded people and rebalance 2 tasks this week.
- Good default: start with workload visibility; add time tracking only if it drives decisions.
- Reading time: ~10–12 minutes.
Core terms referenced: workload, capacity planning, time tracking, utilization, effort vs time.
Purpose, who it’s for, and where it lives
Resource management is about protecting focus: ensuring the right people have the right amount of work at the right time. You’ll use it when deadlines slip because capacity was never visible.
- Who: managers, project leads, ops, and team members coordinating across multiple projects.
- When to use: multi-project environments, shared specialists, and planning for quarters/launches.
- Where in navigation: Resource management capability includes Capacity planning, Workload, and Time tracking.
- Related tabs: Project management (where tasks live), Goals and reporting (outcomes), Admin and security (controls).
Mental model (see load → rebalance → learn)
Resource management is a loop: visualize who is overloaded, rebalance work, then improve planning assumptions. Asana supports this with workload views and (optionally) time tracking data that can feed reporting.
- Visualize: see how busy each person is across time.
- Rebalance: move, split, or reassign tasks to reduce risk.
- Plan: create capacity plans that align resourcing decisions to goals.
- Measure: track time (timer or manual logging) if it improves forecasting and budgeting.
Objects & terms you must know
Even if you don’t track time, you should be clear about how you estimate effort and capacity.
- Workload: view or representation of how busy individuals/teams are across a time window.
- Capacity planning: long-term staffing plans aligned to goals and resourcing decisions.
- Time tracking: record time using an embedded timer or manual logging hours per task.
- Utilization: how much of a person’s available time is already committed.
- Effort signal: can be hours, points, or a simple field like S/M/L—pick one and stick to it.
Core jobs-to-be-done
These jobs turn “we’re busy” into actionable decisions.
- Spot overload early: identify people with too many due-soon tasks.
- Make trade-offs explicit: decide what moves later vs what stays fixed.
- Balance across projects: reassign tasks without losing context/history.
- Budget time realistically: track time only when it changes planning or billing decisions.
- Report on time: include time tracking data in reporting dashboards when needed.
Happy path workflow #1 — Weekly workload rebalance
Use this every week to prevent burnout and missed deadlines. The goal is to end the session with a realistic plan for the next 7 days.
- Pick a 7–14 day window to review (next week is a great default).
- Identify the top 3 overloaded people (too many due-soon tasks or too much tracked time).
- For each overloaded person, list the 3 most important tasks that must stay with them.
- For the remaining tasks, choose one fix: reassign, split, or move the due date.
- Confirm dependencies: don’t reassign a task that requires specialist knowledge without a handoff note.
- Update tasks (owners/dates) immediately so everyone sees the new plan.
- Post a short comment/status summary: what changed and why.
- Repeat until no one is critically overloaded.
Expected outcome: a plan that matches actual capacity, with fewer surprise overdues mid-week.
Happy path workflow #2 — Start lightweight time tracking (only if needed)
Use this when time data changes decisions (billing, forecasting, staffing). The goal is consistent data, not perfect data.
- Define why you’re tracking time (forecasting, budgeting, client billing).
- Decide the minimum rule: track only on specific projects, or only on specific task types.
- Choose a method: embedded timer or manual logging hours per task.
- Set a weekly reminder: log time by Friday (avoid daily perfectionism).
- Review one dashboard chart using time data (e.g., estimated vs actual by section/assignee).
- Use the results to rebalance workload or adjust future estimates.
- If data isn’t used in decisions after 2–4 weeks, stop tracking (don’t create busywork).
Expected outcome: enough time visibility to improve staffing and estimates without turning into admin overhead.
Decision points (when to add more rigor)
Not every team needs time tracking. Use these decisions to keep the system right-sized.
| Situation | Choose A | Choose B |
|---|---|---|
| Work is predictable and deadlines are stable | Use workload visibility only | Skip time tracking |
| Forecasting/billing depends on time | Add time tracking | Don’t guess from memory |
| Overload is caused by unclear priorities | Fix prioritization first | Don’t “measure” your way out |
| Specialists are shared across many projects | Use capacity planning | Don’t let every project plan in isolation |
| People resist tracking time | Track only on high-value scope | Don’t mandate universal tracking without a clear reason |
Guardrails (do/don’t, pitfalls, common mistakes)
Resource management should reduce stress and surprises. If it adds admin burden without decision impact, it’s not working.
Do / Don’t
- Do: rebalance weekly, not only when things are on fire.
- Do: prefer reducing scope and splitting tasks over “heroic” overtime.
- Do: keep effort signals simple and consistent.
- Don’t: use time tracking unless you will act on the data.
- Don’t: treat workload charts as truth; validate with context.
- Don’t: punish teams with time data; use it for learning and planning.
Common mistakes (and how to avoid)
- No ownership: assign one person to run the weekly rebalance ritual.
- Tracking everything: start with a subset (one team or one project).
- Ignoring due dates: workload needs dates to be meaningful.
- Not updating plans: rebalancing only works if tasks are updated immediately.
- Data without action: if charts don’t change decisions, simplify or remove.
Permissions & roles: Not applicable for this tab (see Admin and security). Data & integrations: Time tracking can feed dashboards; see Goals and reporting.
What good looks like + checklists + practice lab
Good resource management produces calm execution: fewer surprises, fewer overdues, and clearer trade-offs.
What good looks like
- Teams can name their top constraints (people/time) clearly.
- Overload is visible before deadlines slip.
- Rebalancing leads to updated tasks (owners/dates), not just talk.
- Time tracking (if used) informs future estimates.
- Stakeholders understand trade-offs without drama.
Pre-check
- Projects have due dates on key tasks.
- Owners are assigned for active tasks.
- One place exists to review workload weekly.
- Effort signal is agreed (hours or simple sizing).
- Team knows how to request rebalancing.
Post-check (after 3 weeks)
- Overdue items trend down.
- Work is reassigned/split earlier, not at the last minute.
- Estimates improve (less chronic under-scoping).
- People report fewer “surprise” high-priority tasks.
- Time tracking (if used) is complete enough to trust.
Practice lab (10–15 min)
Goal: run a mini rebalance session for the next week.
- Pick one team project with at least 15 tasks.
- List the top 5 tasks due in the next 7 days.
- Identify 1 person with too many due-soon tasks.
- Reassign or reschedule 2 tasks and add a short comment explaining the change.
- If time tracking is enabled, log time for one task and see how it shows in reporting.
Verify you did it right: the project now shows a realistic plan and at least one overload risk was removed.
Official docs links
- Resource management (capability overview) — capacity planning, workload, time tracking
- Workload — visualize and rebalance load
- Time tracking — timer/manual logging and reporting
Asana — Admin and security
Based on Asana’s official “Admin and security” capability (Admin console, permissions/access controls, team/guest management, trust & compliance messaging).
Quick scan
- Outcome: the right people see the right work, guests are controlled, and admins can manage org settings centrally.
- Fast win: define a guest policy + default sharing expectations before scaling usage.
- Good default: keep governance lightweight but explicit (who can invite, share, export, and administer).
- Reading time: ~12–15 minutes.
Core terms referenced: admin console, permissions, access controls, guest management, compliance/trust.
Purpose, who it’s for, and where it lives
Admin and security keeps collaboration safe as your organization grows. It’s for administrators who need to manage users, permissions, and sharing so work stays private where needed and visible where it should be.
- Who: org admins, IT/security, operations, and team admins.
- When to use: onboarding many users, collaborating with vendors, compliance requirements, controlling sharing.
- Where in navigation: Admin and security capability includes Admin console, Permissions and access controls, Team management, and Guest management.
- Related tabs: Integrations (tool access), Project management (where permissions apply), Workflows (forms can be externally shared).
Mental model (governance as guardrails)
Think of governance as guardrails, not roadblocks. You define defaults (sharing, guest rules), control who can administer and invite, and periodically review membership and access to keep things clean.
- Define policies: who can invite guests, who can create teams/projects, what must stay private.
- Configure controls: set org-wide permissions/access controls.
- Manage membership: add/deactivate users and review seats and invites from the admin console.
- Audit & improve: export membership data when needed; review sharing and guest usage regularly.
Objects & terms you must know
These terms help you talk about access precisely across teams and projects.
- Admin console: a central place to manage org settings, members, permissions, and security options.
- Permissions/access controls: org-wide controls for how work is shared and who can access it.
- Member vs guest: guests are external collaborators with limited access to what is explicitly shared.
- Team management: controls around admins, member settings, and governance for teams.
- Compliance/trust: Asana positions security, reliability, and compliance as part of its trust offering.
Core jobs-to-be-done
If you can do these five things, your org stays safe while still moving fast.
- Onboard securely: invite users with a clear standard for where work belongs (teams/projects).
- Control sharing: set expectations and controls for what’s public vs private.
- Manage guests: allow external collaboration while preventing over-sharing.
- Audit membership: view/search/sort members, deactivate leavers, and export membership data.
- Scale governance: assign admins appropriately; keep policies simple and enforced.
Happy path workflow #1 — Set up baseline access governance (starter version)
Use this before you invite a large group. The goal is to avoid chaotic sharing and unclear ownership of admin responsibilities.
- Decide who the primary admin is (one accountable owner for governance).
- Write a simple policy: what belongs in Asana, and what must not be stored there (if any).
- Define your guest policy: when guests are allowed, and who can invite them.
- Define default expectations for project/team privacy (public vs private by default).
- Assign team admins (or responsible owners) for major teams if your org is large.
- Set up a monthly review: new invites, guest list, deactivations, and access exceptions.
- Communicate the policy in one place (a “Read first” project or pinned doc).
Expected outcome: clear ownership, predictable sharing behavior, and fewer security surprises.
Happy path workflow #2 — Member lifecycle: onboard, manage, offboard
Use this as a standard operating procedure. The goal is to keep access accurate and remove stale accounts quickly.
- When onboarding: add the person, assign them to the correct teams, and share the “Read first” project.
- Confirm they can access the right projects and cannot access restricted projects.
- When roles change: update team memberships and project memberships (don’t leave broad access lingering).
- When someone leaves: deactivate them promptly and reassign ownership of critical tasks/projects.
- Review pending invites and guests monthly.
- Export membership data to CSV when needed for audits or review cycles.
- Document exceptions: any special access should have a clear reason and end date.
Expected outcome: active membership reflects reality; least-privilege sharing is easier to maintain.
Decision points (practical security choices)
These choices prevent the most common governance and privacy mistakes.
| Situation | Choose A | Choose B |
|---|---|---|
| Work includes external vendors | Use guests with explicit sharing | Don’t invite externals as full members |
| Teams must collaborate widely | Set clear default sharing guidelines | Don’t rely on tribal knowledge |
| High sensitivity projects exist | Default to private + controlled membership | Don’t leave sensitive work broadly visible |
| Admin work is scattered | Centralize ownership in the admin console | Don’t let every team “do their own thing” without oversight |
| Need compliance evidence | Use audit/exports and documented policies | Don’t wait until audit time to clean up |
Guardrails (do/don’t, pitfalls, common mistakes)
Security failures are usually process failures: unclear policies, unmanaged guests, and slow offboarding. Keep it simple and enforceable.
Do / Don’t
- Do: define who can invite guests, and when.
- Do: review membership and invites regularly.
- Do: keep sensitive initiatives private by default.
- Don’t: allow “everyone can share everything” without clear guardrails.
- Don’t: leave ex-employees active; offboard quickly.
- Don’t: treat governance as a one-time setup; it’s a routine.
Common mistakes (and how to avoid)
- Guest sprawl: keep a single owner responsible for guest reviews.
- No default rules: publish a simple “sharing playbook” for teams.
- Too many admins: restrict admin roles to trained owners.
- Unclear privacy: use project/team privacy settings intentionally, not accidentally.
- Audit panic: schedule a monthly lightweight review so audits aren’t emergencies.
Data & integrations: Applicable (admins may control integration access and data governance). See Integrations and the Developers docs if you build custom apps.
What good looks like + checklists + practice lab
A good admin setup is invisible day-to-day but prevents major mistakes. People can collaborate fast, and you can still answer “who has access?” confidently.
What good looks like
- Admins are known and accountable.
- Guest invitations follow a clear policy.
- Sensitive work is private by default.
- Offboarding happens quickly.
- Membership can be reviewed/exported when needed.
Pre-check
- Primary admin is assigned.
- Guest policy is written and shared.
- Default sharing expectations are documented.
- One monthly review ritual exists.
- Teams know where to ask for access exceptions.
Post-check (after 1 month)
- Guest list is reviewed and cleaned.
- Pending invites are monitored.
- Offboarding is prompt and consistent.
- Teams follow privacy defaults more often than not.
- Fewer accidental over-sharing incidents.
Practice lab (10–15 min)
Goal: write a minimal governance playbook and test it.
- Draft a 10-line policy: who can invite guests and when.
- Draft a default sharing rule: which projects are public vs private by default.
- Create a “Read first: How we use Asana” project and add the policy as the first item.
- List 5 checks to run monthly (invites, guests, deactivations, exceptions, sensitive projects).
- Share the playbook with one team lead and ask: “Is anything unclear?”
Verify you did it right: a teammate can explain the guest policy and where sensitive work should live without guessing.
Official docs links
- Admin and security (capability overview)
- Admin console — manage org settings and members
- Permissions and access controls — org-wide privacy and sharing controls
- Object hierarchy (users, guests, teams, workspaces)
Asana — Integrations
Based on Asana’s official features navigation (Integrations) and the Asana developer platform docs for programmatic integrations.
Quick scan
- Outcome: reduce app-switching by connecting Asana with the tools you already use (Slack, Google, Microsoft, Jira, etc.).
- Fast win: pick one integration that captures action items into a project (then measure adoption).
- Good default: start with official apps, then consider API integrations only when needed.
- Reading time: ~10–12 minutes.
Core terms referenced: integrations directory, OAuth/PAT (API auth), rate limits, pagination, webhooks (advanced).
Purpose, who it’s for, and where it lives
Integrations help you capture work where it happens and keep systems in sync. You’ll use them to turn messages, meetings, and external system events into trackable tasks and updates.
- Who: teams trying to reduce context switching, ops teams standardizing tooling, and developers building custom workflows.
- When to use: turning chat/email into tasks, syncing work with systems like CRM/issue trackers, reporting cross-tool data.
- Where in navigation: Integrations section highlights common apps (Google, Microsoft, Salesforce, Slack, Zoom, Jira, Tableau, PowerBI, etc.).
- Related tabs: Workflows and automation (rules/forms), Admin and security (permissions), Goals and reporting (dashboards).
Mental model (choose your integration level)
There are three levels: (1) use an official app integration, (2) automate within Asana using rules + forms + templates, or (3) build custom behavior with the Asana API. Start simple and move up only if you must.
- App integration: connect a tool and use built-in actions (best for most teams).
- In-Asana automation: route and standardize using rules/forms/templates.
- API integration: build custom workflows (requires auth, pagination, and rate limit handling).
Objects & terms you must know
Even if you never write code, these concepts help you evaluate integration options and security trade-offs.
- App directory: catalog of integrations maintained by Asana and partners.
- Asana API: programmatic access to tasks, projects, portfolios, goals, and more.
- PAT (personal access token): simplest API auth option; long-lived token with the same authorization as the user who created it.
- OAuth: recommended when multiple users need to sign in through your integration.
- Rate limits: API request quotas per minute depend on domain type (free vs paid tiers).
- Pagination: large result sets are paged; API may return an offset for next page.
Core jobs-to-be-done
These are the integration outcomes that matter most for beginners.
- Capture action items: turn chats/meetings into tasks in a consistent project.
- Reduce duplicate data entry: keep one source of truth for status and next steps.
- Sync across tools: connect Asana work to systems like CRM, ticketing, or docs.
- Improve visibility: pipe key fields into dashboards and portfolio summaries.
- Keep it secure: choose the right auth method and permissions model.
Happy path workflow #1 — Add one integration safely (non-technical)
Use this when a team keeps losing action items across tools. The goal is one reliable capture path with minimal disruption.
- Pick one use case: “capture action items from meetings into Asana”.
- Select one integration (start with the tool you use every day, e.g., chat or calendar).
- Create a destination project in Asana: “Incoming action items”.
- Define a simple intake structure: New → Doing → Done.
- Connect the integration and point it to the destination project.
- Run 3 test captures and confirm tasks include the minimum details (owner, due date if applicable).
- Share a 5-step “how to capture” instruction to the team.
- After a week, review: are people using it? If not, simplify the flow.
Expected outcome: action items consistently land in one place and are converted to owned tasks.
Happy path workflow #2 — First API integration (technical, minimal)
Use this only if you truly need custom behavior. The goal is a safe first step: authenticate and create a task programmatically.
- Start with Authentication and choose a method.
- If it’s a personal script or single-user tool, use a personal access token (PAT).
- If multiple users must sign in, use OAuth.
- Create one task via the API (prove the integration works end-to-end).
- Handle pagination for any list endpoints you depend on.
- Respect rate limits and back off when needed.
- Store tokens securely and follow least-privilege access principles.
Expected outcome: you can authenticate safely and perform a basic create/read flow without breaking on large datasets.
Decision points (pick the right integration approach)
These decisions prevent you from overbuilding or creating security risk.
| Situation | Choose A | Choose B |
|---|---|---|
| You can solve it with an existing app | Use an official integration | Don’t build custom code |
| You need consistent intake and routing | Use forms + rules | Don’t wire up multiple tools first |
| Single-user script or narrow internal need | Use PAT auth | Don’t implement OAuth unless required |
| Multiple users need to connect accounts | Use OAuth | Don’t share one token across many users |
| You fetch large lists of tasks/projects | Implement pagination + respect rate limits | Don’t assume “it returns everything” |
Guardrails (do/don’t, pitfalls, common mistakes)
Integrations can quietly create messy data or security issues. Keep scope narrow and build in safety.
Do / Don’t
- Do: start with one use case and one destination project.
- Do: document what the integration creates/changes in Asana.
- Do: keep permissions minimal; use admin review where appropriate.
- Don’t: create tasks in many projects without a consistent naming convention.
- Don’t: share access tokens loosely; store them securely.
- Don’t: ignore pagination and rate limits in API-based integrations.
Common mistakes (and how to avoid)
- Too many integrations at once: add one, stabilize, then add the next.
- Unclear ownership: assign an integration owner for maintenance and support.
- Data duplication: avoid creating duplicate tasks; use consistent linking and structure.
- Token misuse: PATs are fine for narrow scope; use OAuth for multi-user apps.
- Scale surprises: large workspaces require pagination and careful rate-limit handling.
Permissions & roles: Applicable (integrations can widen access). Coordinate with Admin and security for governance.
What good looks like + checklists + practice lab
A good integration is invisible: it reliably creates the right tasks and doesn’t create noise or security risk.
What good looks like
- One clear use case and one clear destination.
- Tasks created are consistently named and assigned (or triage-ready).
- Minimal permissions and clear ownership.
- Low noise: no duplicates, no spammy updates.
- For API: pagination and rate limits are handled safely.
Pre-check
- Destination project exists with intake sections.
- 3 test events were run end-to-end.
- Team knows how to use the integration.
- Integration owner is named.
- Admin/security review is done if required.
Post-check (after 2 weeks)
- Adoption increased (more captured work, fewer lost action items).
- Noise is low (few duplicates/incorrect routing).
- Issues have an owner and a fix path.
- Security posture is acceptable (no broad token sharing).
- System remains understandable for new teammates.
Practice lab (10–15 min)
Goal: integrate one tool into a single intake project.
- Create a project: “Captured action items”.
- Pick one tool you use daily (chat or meetings).
- Connect it so action items land as tasks in the project.
- Submit 3 test items and verify naming + ownership.
- Write a 5-step usage guide in the project description.
Verify you did it right: your team can capture action items without switching apps, and the tasks land where they should.
Official docs links
- Integrations (feature overview) — common tools list
- Asana Developers program — build integrations with the API
- API authentication — PAT and OAuth guidance
- API rate limits — request quotas by domain type
- API pagination — offsets and large result sets
