You won’t find a bigger Asana evangelist than me. But there’s one feature I’ve never been able to use properly: tags.
When you have a paid Asana account, you quickly rely on custom fields for everything. Still, tags are used by free users and even some paid ones. I tried for a long time to make them work, and eventually gave up because they just had too many flaws.
Recently, I found the perfect use case and decided to give tags another shot. I started coding, feeling hopeful—and then, once again, tags managed to disappoint me. I wanted to edit tags on a task while editing other fields using an API call, and realized I needed to use a completely different endpoint for tags.
Not sure about @Bastien_Siebman but for me, I want to use tags for the following:
I can trigger actions globally via the API, Zapier, etc. based on when a tag is added to a task without having to first specify the project.gid which makes life a lot easier when I want some set of actions to occur universally across every project. This is their single most useful capability for me.
Similarly, combined with the above, I can configure a trigger and an action to add a tag when some set of condition exists within a project, which then triggers #1 above.
Beyond that, within the app itself, I like tags for things like:
Being able to add context to a task card on the board view without taking extra space that a custom field would. For example, we have a custom field for “Class of Service” (CoS) with options like Expedite, Fixed, Standard, and Intangible. When we set the CoS, it triggers an automation to add a correspond tag for that CoS, so we can see it on the card without taking up more real estate and cluttering things since the way cards display custom fields is jumbled mess.
Being able to click a tag and see all items with that tag. This is nice because it’s way faster than using an advanced search, having to add more clutter to favorites by saving it (since saved searches and favorites were combined for some reason awhile back), or having to rely on saving a bookmark to the search with all its query params.
I need to mark a few tasks with a specific “data point” and didn’t want a field to apply to all tasks. It almost never happens, but I know some people use them a lot. cc @Bryan_TeamKickstart
@Skyler - yes I agree with all four things you said. They are the simplest, org-wide method for triggering an automation in a user-friendly way without the liabilities that come with adding a custom field everywhere. And everything else you said. I just hope somebody will see the light and re-decide to fully support them everywhere.
To me, a main unique benefit of tags is to apply — ad hoc/on-the-fly — an attribute or attributes to tasks that are (often sparsely) distributed across an instance, particularly spanning unrelated projects, making existing solutions (custom fields or multihoming) less helpful. And, of course, to then easily see groupings of those tasks marked in that way. Also, the unique ability to target with the API as pointed out already.
I understand that there are troublesome technical limitations internally with tags, so I’d like to see support for the above capabilities in whatever way makes sense; potentially, some solution other than the problematic existing Tags implementation.
When I’ve used tags, I’ve often used them as structured sets of tags following this kind of pattern:
pri
pri-high
pri-med
pri-low
and then always assigned a pair of tags:
'pri`, accompanied by
one of the other three
…so Tag Views were available for all tasks:
that had any priority tag at all, and
only a specific priority
I found that useful both when the specific tags were mutually exclusive (like the priority example) and when they were not mutually exclusive.
Wanted to chime in and say I use the same approach to naming tags as @lpb here:
cos
cos/expedite
cos/fixed
cos/standard
cos/intangible
Using this approach allows us to reduce duplicate tags across the instance (through the use of hierarchies) while also still preserving what I believe is the core essence of tags across most systems: flat hierarchical structures.
Where the top level, when used on its own is meant to be combined with n tags to provide additional context and avoid the pitfall folders cause in information management.
A item may benefit to belonging to many different “contexts” at once. Tags enable this.
Multiselect fields also help accomplish this, but, as mentioned, sometimes you don’t need a custom field for that or the values you would harbor in it are so vast and varied it doesn’t make sense to use a multiselect field.