My company uses ASANA to track all our products currently in progress. It would be great to be able to add a project tag that then allows us to filter by the product name when looking at workload/calendars. Emojis and task tags don’t work for what we’re looking for.
@April_McCaffrey are you thinking of something like Project-level Custom Fields?
here’s some Asana support articles for reference:
Not exactly. I use custom fields quite extensively and they are very handy, but what I’m referring to more is a high level label that can be added to a project template so that it doesn’t need a manual custom field added each time.
For example, in a HR team, having the Offboarding template labelled with “Offboarding”, an Onboarding template with “Onboarding”, a Probation template, etc. Then being able to sort in the workload under each person by the type of project they’re currently working on as well as having the data of how many of a type of project is currently live.
Ohhhh I see what you mean—that makes total sense, I’m all for it! 
So beyond just applying tags to a project, you’re asking for the Ability to pre-select a value for a Custom Project-level Field within a Project Template essentially?
1 Like
My hesitation to say custom field as a whole rather than a tag is because custom fields aren’t visible in the workload/capacity calendars, and can’t be filtered for in these areas. My ideal would be having the tag visible next to the title and icon of the project with a built filter option.
It’s not a complete solution, but our team uses portfolios for this. Each of our project templates is auto-linked to 1+ portfolios (so in your case, you’d have an onboarding portfolio, offboarding, etc.) and then you can filter workloads to only include projects from certain portfolios.
I believe Asana is generally moving away from tags and towards custom fields, but I agree that not having those fields as filter/visible options in workload and other areas of the platform is a challenge currently.
1 Like
Oh wow I had no idea custom fields weren’t used in those parts of the platform—that’s surprising!
Conceptually this definitely works—I like it!
Where I’ve had issues is with adoption.
People seem to really want to keep things to a single Portfolio whenever possible so they have their one place to go. And then within that portfolio they want to have Tabs that slice and dice all the views.
Have you encountered this obstacle?
Any advice?
Projects can be in many (unlimited? or definitely a LOT) portfolios, so they could have their go-to portfolio and this separate one(s) just for reporting purposes. We do something similar where all projects sit in one portfolio and then we have an array of other portfolios we use to mimic specific fields (we also use this for reporting since you can’t do task reporting filtered by project-level field info).
Definitely makes sense to me. I’m just finding that people have been averse to the idea of navigating to a different portfolio just to see a view that is a specific subset of an existing portfolio of projects. The strong preference seems to be leveraging tabs/views within that portfolio to see the different subsets.
Regarding @April_McCaffrey’s original request, the other part of the solution is that a portfolio rule could default that custom field to the “tag” value you want. You could do this with one portfolio for each tag (and still have one overall portfolio for all projects to be found in).
Thanks,
Larry
2 Likes
ohhhh interesting idea @lpb!
So essentially you’d
- have each template automatically add new projects to the main portfolio & their respective portfolio, then
- within that portfolio there’s a rule to set the custom field value to match, and then
- back in the “main” portfolio those projects all now have the values set accordingly and
- you can now create views filtered based on those values.
And no one really even needs to know those portfolios exist, they’re just performing this one function behind the scenes. I like it!
1 Like
Exactly! Now I haven’t tested this, but unless I’ve forgotten something, I think it should work this way.
The custom field needs to be added to your org’s library (shared custom field) and needs to be added to both portfolios in your example.
Thanks,
Larry
1 Like
That’s a good idea as a workaround. I used HR as an example, but for me it’s needing the data of how many projects are live for client vs. internal products, by provided and bespoke products. I will check the company’s portfolio limit (if any) as it would be creating upwards of 50 portfolios. I can ask the relevant people to update the templates too.