Sooner or later, a lot of teams' Asana workspaces drift into the same state. Picture it: an operations lead scrolling through the company's Asana, stopping at a project called "Q3 Launch". Untouched since June. Then another. And another. Fourteen projects, and maybe three of them are trustworthy. The rest are museum exhibits.
Some clients come to me after living exactly that scene. Others book a call wanting something that sounds unrelated, better reports, cleaner automation, a smarter intake process, and it turns out the workspace underneath is the thing holding all of it back. Either way, the diagnosis is the same: you cannot fix a graveyard by asking people to try harder.
A workspace everyone abandoned is a design problem. People stop updating systems that don't pay them back for the click. And once a few projects go stale, the whole thing loses authority. Nobody believes the board, so nobody checks it, so it goes staler. Work retreats into Slack threads and a private spreadsheet, which is exactly the outcome Asana was supposed to prevent.
The same handful of design mistakes shows up in almost every rebuild I run, whether the team arrived with the symptom or discovered it along the way. This is the teardown, in the order I run it.
Start with what the workspace is actually for
Before touching a single project, I ask the team one question: if this workspace were perfect, what decisions would it help you make on Monday morning?
Answers are usually vague at first. "Visibility." "Accountability." Neither of those is a decision. Real answers sound like: "know whether we can take on the new client," "see which deliverables slip this week," "know who's blocked before the Friday meeting." If the leadership team cannot name the decisions the workspace supports, every design choice after this point is guesswork.
This question matters more than any feature. Asana can be configured a thousand ways, and most of them are fine. What separates a workspace people use from one they abandon is whether opening it answers a question someone actually asks. My free guidebook, Asana 101, covers the mechanics. Chapters 1 through 3 are the best starting point for fundamentals; this post is about the judgment calls the guidebook can't make for you.
The teardown, in the order I run it
Custom fields first, because they set the ceiling
Custom fields are the schema of your workspace. They decide what you can see, group, and sort by, and they are the single biggest difference between a workspace that answers questions and one that just holds task lists.
The failure pattern is always the same. Someone adds a field for a one-off need. Then another person adds a competing field for the same idea. Six months later there are five priority fields, none of them used consistently, and a dropdown with 14 options nobody can distinguish. Every new field taxes every future task creator, and the payoff never comes.
What a rebuild looks like:
- Inventory every field across every project. List them all in a sheet. It is usually embarrassing. I've seen workspaces carrying "Priority," "Priority Level," and "Urgency" as three separate fields across projects, each with a different option list.
- Merge to one owner per concept. One priority field. One status field. If two projects genuinely need different option lists, that is a signal they are doing different kinds of work and should be split. And remember custom fields live at the project level, so design the shared ones where they can be reused.
- Cap the options. If a dropdown has more than about five options, people guess. Five options a person can distinguish beats fourteen they can't.
- Delete shamelessly. A field nobody groups or filters by is decoration. Deleting it is not a loss.
One more thing worth saying: fields that don't get filled in aren't a training problem either. If a field keeps coming up empty, the workflow it was designed to support doesn't exist yet, or it's the wrong field for the workflow.
Custom fields are the schema of your workspace. Everything you will ever group, sort, or report on depends on getting them right early.
Reduce projects until it hurts
The second pattern is project sprawl. "Q3 Launch" sits next to "Q3 Launch v2" next to "Q3 Launch FINAL". Or the team has one project per client per year, and leadership can no longer see anything across them.
More projects means more places to look, more rules to maintain, and more chances for a task to live in the wrong one. Every rebuild pushes toward fewer, longer-lived projects with something that distinguishes the work inside them, usually a custom field or a section. I have seen a 26-project sprawl collapse into 6, and the portfolio view the team was already paying for suddenly earned its keep.
A rough threshold: if a project exists to hold work that is already finished, it is an archive, and archives don't belong on the active dashboard. Asana completes and archives cleanly. Move it out of sight and out of mind.
Sections should read like a pipeline
Open any project and read its sections out loud. In a healthy project they sound like a pipeline: "Intake, Scoping, In Progress, Client Review, Done". In an abandoned one they sound like a junk drawer: "To Do, In Progress, Blocked, Misc, New, misc (2)".
Sections are the visible workflow. When they're vague, people have to decide where a task goes every time, they guess, and the board stops meaning anything. When they're concrete, placement is obvious and the board becomes a status meeting you can hold in front of a screen without any preparation.
One project, one owner
Every active project needs a person whose job is the board itself. Not the work, the board. When a project has no owner, stale sections and duplicate tasks persist because "someone should clean that up" is nobody's actual job. In most small teams this is less work than it sounds, maybe an hour a week for a busy project, and it is the difference between a board that reflects reality and one that reflects last quarter.
The noise problem: why work decays back into Slack
Here is the part most teams get wrong, and it is the reason rebuilt workspaces decay again within six months.
When everything in the workspace announces itself, the team learns to ignore it. Every task assignment fires a notification, every due date change pings someone, every comment triggers an email. Within a month, the team's survival instinct is to tune the whole channel out. Once that happens, the board is no longer the communication system. Slack is. And Slack has no memory anyone can search by due date or status.
The fix is to make Asana quiet by default and loud only when it matters:
- Turn off email notifications for routine events like assignments and comments, except for the two or three people who actually want them.
- Let the board do the broadcasting. A status meeting in front of a clean board replaces a hundred "any update on this?" pings. The board updates continuously, so the meeting gets shorter, not more frequent.
- Route exceptions, not everything. A rule that fires only on real exceptions (see the next section) beats forty notifications nobody reads. Attention is the resource you are protecting.
If your team hears from Asana twenty times a day, they will make sure they never hear from it at all.
Custom fields are the backbone of automation
This is the part most teams completely miss, and it is where the custom fields work from earlier stops being housekeeping and starts paying rent. Automation rules in Asana run on two things: events ("something happened") and information ("what exactly happened"). Custom fields are how you supply both.
- Fields as triggers. A stage field is not just a label, it is a switch. When a task moves from "In Progress" to "Ready for Review", a rule can fire on that exact change and post a comment tagging the person who is supposed to do the review. The field change is the trigger; the review never waits for someone to remember.
- Fields as information. The trigger answers "when", the field answers "who". If a custom field captures the designated reviewer, the rule knows exactly whom to tag. Same pattern for anything routed by type, priority, or owner: the rule reads the field and acts on it.
- Fields that update themselves. The relationship can run the other way too. Say every team member has an assigned supervisor or reviewer. A rule can look at a task's assignee, find that person's supervisor, and write the supervisor into the reviewer field automatically. Review routing maintains itself instead of being maintained by hand.
- Fields Asana can fill in. Asana AI can do the data entry in the right setup. Say you run a collection of mid-to-long-term projects with launch dates, and you want to see which projects land in which quarter and filter by quarter. Instead of making Asana read raw dates, add a custom field with Q1 through Q4 as the options, then let Asana AI pick the right quarter from each project's launch date. Add a year field next to it and you can monitor and filter projects by quarter across multiple years.
That last one is worth pausing on. A dropdown that a person would have to maintain by hand, kept current by the system itself, turns a pile of dated projects into something sortable, filterable, and actually consultable. That is the whole game: fields chosen deliberately become the raw material your rules and dashboards run on. Fields chosen carelessly become the five competing priority columns.
Automation runs on events and information. Custom fields are how a workspace supplies both.
Event rules are not the only kind worth having, by the way. Rules that run on a schedule have their own place, and neither kind diminishes the other. A rule that checks the workspace once a night and finds every overdue task can move those tasks to an Overdue section and bump their priority to Critical. Nothing "happened" to trigger it in the moment; the clock did. I use both kinds deliberately: event rules for the moments work changes state, scheduled rules for the housekeeping that should happen whether or not anyone remembers. What I avoid is treating either one as the answer to everything.
The pattern stretches further when a rule can reach outside Asana. Say a task moves to a stage like "Purchase history needed". The rule calls your own application, pulls that customer's purchase history, and writes the details onto the task. Then it flips the stage to "Purchase history available", and that change is itself a trigger: the assignee gets notified, with everything they need already sitting on the task. Nobody had to go find the information, and nobody had to remember to ask for it. (On the simpler end, posting to Slack does not need any of this machinery; the native Asana-Slack integration already covers it.)
The design rule I follow still applies: write the process down before you automate it. If the team cannot describe the workflow in a sentence, no rule can encode it. Chapter 4 of my Asana 101 guidebook walks through writing the rule before you build it, then automating with guardrails.
When clean fields and sensible rules are in place, the workspace starts paying the team back for every click. Fields become filters and dashboards that answer the Monday-morning questions. Rules handle the clicks nobody wants to make. That's when updating the board becomes the fastest way to communicate status, and the graveyard pattern stops.
Rules do have a hard limit: they only fire on the events Asana itself can see. They cannot read the messy stuff, unstructured client emails, a Slack thread where the scope changed, a screenshot of a whiteboard. That is where AI agents enter, and it is also where most teams should be conservative. If you're curious about that boundary, I wrote about why your automation needs a human approval gate, and my guide to custom AI agent development covers when reasoning is worth the complexity. My general stance: fix the workspace first. Agents on top of a broken workspace just break things faster.
Where rebuilds go wrong
- Boiling the ocean. Fixing 14 projects at once means none get fixed. Pick the one project leadership actually looks at, fix it, let the team feel the difference, then roll out.
- Inventing process. The workflow on the board should describe what the team already does, compressed to its cleanest version. A redesign that forces people to change how they work just to satisfy the board is where rollouts die.
- No owner. Without a board owner, the workspace decays right back. Rebuilds without an owner are a six-month countdown to this article again.
What a fixed workspace feels like
The test is boring. Open the workspace on Monday morning and ask the questions from the first section. Can leadership see which deliverables slip this week? Can you tell who's blocked before the Friday meeting, without asking anyone? When a client asks for status, is the answer on a board rather than in someone's memory?
When those answers are yes, work stops leaking into Slack threads and private spreadsheets. The board becomes the place where status lives, and the team keeps it alive because it is faster than the alternative.
None of this takes new software. It takes a weekend of decisions: which fields survive, which projects merge, which sections mean what, who owns each board. If you want someone to run those decisions with you and do the rebuild properly, book a call and I'll walk your workspace with you.
