Don't use a "Priority" custom field (usually); use a simpler approach, or a "Critical" ✔️ instead

I’m not a fan of the Priority custom field! Nine out of ten times I see it used by clients, I feel they’re wasting time and recommend they remove or replace it.

A Priority field is shown in many Asana demo videos and is included by default in many Asana-provided project templates. I feel most of these are not optimal.

Simpler Approaches

In cases where a task has a Due date set, a Priority custom field often is redundant; the Due date effectively conveys the priority, so a custom field is not needed.

I always first try to use the position of the task in the tasks list to convey priority by using grouping and/or order.

In My Tasks, I have sections including Now, Today, or This Week to group tasks by priority; no Priority custom field needed. In deadline-bound projects, sections indicate Phases or workback structure (Six Months Out, One Month Out, Week Of, Day Of) to group work. And in each of these cases, I maintain priority and/or chronological ordering within the sections instead of using a Priority custom field.


I feel the above approach is simpler (better organization, less visual clutter) and more efficient (you don’t have to set the value of an extra custom field value for every single task). That last point is crucial: More often than not, when a Priority field is included, people forget or don’t bother to set these values for many tasks. What does that mean, then? That its priority is undefined for some reason? Or does it mean that it’s a Medium priority? Then why have Medium as a value too? And for that matter, how often do you see Low or Medium values used? In my experience, the most used values are High and not set.

Preferred Alternative

If you really do need to indicate importance beyond using the Simpler Approaches I suggest above, I recommend using a Critical or Hot custom field. Make it a single-select type but with a single option value: :heavy_check_mark: (checkmark emoji) or :fire: (fire emoji). (This is effectively creating a checkbox field depicted as a single-select type field because Asana doesn’t offer a checkbox appearance, but we can simulate it this way)

There’s no task-by-task overhead of setting a value (as there is for setting Medium) because the unset default is usually what you want (most tasks are not critical).

It stands out more than High because it appears in a column of otherwise mostly empty cells.

You don’t have to decide if it’s Medium or Low, often a meaningless distinction.

When to Correctly Use Priority

I hedged in this post’s title using the word “usually.” There are legitimate and valuable uses for a Priority custom field.

One example: If you do sprints and have a Backlog project, it’s helpful to have the backlog prioritized; High, Medium, and Low have strong meanings here.

You could do that with sections as mentioned in Simpler Approaches, but using a custom field might offer more flexibility (use of filters, rules, appearance elsewhere when multi-homing, etc.). And you could still sort (group) in List view by Priority to effectively turn the High, Medium, and Low values into what appear like project sections.

No Free Lunches

Priority is the only free custom field Asana makes available to the Asana Basic plan. Don’t use it just because it’s free!

I wish Asana would provide my Critical :heavy_check_mark: custom field above as a built-in custom field and also make it available in the Basic plan. and use it instead of Priority in demos and Asana-provided project templates.

Thanks for reading,



So true! :sweat_smile:

You make a great case @lpb !


I do agree in a way but also think that better clarification on the task priority could help.
I do not like the low, Medium, High options.
But I am playing around with the following options (even just in the My Task view)

P0: Immediate action - critical tasks that must be completed immediately
P1: Important tasks - high priority tasks that have a significant impact on the project
P2: Reasonable timeframe - important tasks that can be completed within a reasonable timeframe
P3: Minimal impact - low priority tasks that have minimal impact on the project
P4: Delayable tasks - very low priority tasks that can be delayed without significant consequences
P5: Skippable tasks - optional tasks that can be skipped if necessary


@lpb I agree 100% and have been advocating for this for years. People have Low-Medium-High, they often don’t set any priority so they actually have a fourth value, and most people don’t update it correctly.

At iDO we have a single “:fire:” priority and that’s it. We have an automation adding the fire at the beginning of the task names to make it stand out.


I love this suggestion! As a project manager, I have spent WAY too much time adjusting the priorities of different tasks on my team members’ schedules, only to realize that the field gets ignored anyways. I didn’t really have a replacement for this, though, so I just stopped using it altogether. I like the idea of having the custom field to mark the tasks that truly are the highest priority. Thanks for the idea!


I’m probably in the minority here, but I love using High, Medium, Low priority on tasks!

At our marketing agency, we base it on how likely these tasks can help us achieve our Annual KPIs. If it’s a low priority, we look at either pushing the due date further back or deleting it entirely. This makes it really easy to summarize whether we are on-track or off-track every month.

It’s also useful in helping us moderate how much capacity we have as a team. When new tasks get added without removing a low-priority task, we know we’re stretching ourselves thin and might need to relook at the plan.

As for the due date, Priority is separate from how we gauge “urgency” or how quickly we need something done.


I totally disagree, we use priority as we have such a large volume of work and resourcing can sometimes be limited. We use High/Medium/Low as a MosCow Agile prioritisaiton technique.

All our planning and resourcing is focussed on trying to prioritise High and Medium and team members know that Low’s are often shorted less complex tasks that they can fit in around other wor.

It helps us and them with prioritisation. I do accept this won’t work for every use case but as a very experience project manager this really is an essential field for teams to use as long as everyone is using it in the same way and it’s embedded across the team.

That’s the hardest, when 90% of people don’t update the priority field, it doesn’t mean anything anymore. That’s what I base my “common rule” on :grimacing:

1 Like


Thanks for your thoughtful reply. I think we’re in agreement, actually! That’s certainly a good use of Priority which I’d see as another example for this section:



It’s all about team workflow and embedding processes isn’t it?

Yes, as well as having someone to do maintenance (and chasing people to fill in required info for example).

1 Like

Good points on both sides! It’s true that the priority field is often overlooked when people create the tasks -the workaround I’ve always used is using an automation: every time a task is added to a project, the priority is automatically set to the lowest: this is a mind trick which “forces” the people to actually see that the priority was prepopulated and think “wait, that’s not the lowest priority, let me change that”, and in my experience this has always worked. Fwiw we use 4 priorities only based on the important/urgent: P0 - Do (important & urgent), P1 - Fix (Not important, Urgent), P2 - Plan (Important, Not Urgent), P3 - Trivia (Not Important, Not Urgent)