Custom fields are my favorite topic as of late!
I don’t tag a lot of items and I never really did, however there are a few that I use that have stood the test of time, so to speak.
I use this to collect all the templates I have set up across the organization. I have access to the custom project templates now (yaay!) which will be available soon to everyone I think, but what about task templates? That’s where the tag comes into place. When I’ve created a new process task, or something that is replicated a lot, I tag it as a template.
Then, when I go to copy the task I just make sure to remove the tag. I never really used the word/naming convention of naming tasks as templates, I just used the tag. That way I can click on it (it’s on my sidebar) and see all of the templates for processes across the organization.
I go to a lot of meetings, and they don’t always belong to a project initially (or maybe not a project that I own/doesn’t live in Asana, etc.). But I know I need to take notes, if not officially than for myself. I have a Zap set up via Zapier where every time an event is added to my calendar, a task is created for me that is tagged with “Meeting Notes”.
Then I can review upcoming meetings, write down agenda topics or points I want to bring up, etc.
It’s also useful for when I want to go back to my personal notes for xyz meeting, I just pull up the tag and find it, etc. and for wading through “My Tasks” I can easily see that those are meeting notes, whereas custom fields don’t (yet) show up there, and so I need to go through the notes and check if there are/were any action items that I need to create tasks for.
And of course if it lives in a project, it’ll be public to whomever needs to see it. So for execs or people who just want to see meeting documentation, they can pull up the tag.
I have a lot of budget-related references that I need to keep around for check-ins (like SAP codes, which email to send xyz to, etc.) and I’ve found it’s really helpful to have standing unassigned tasks with that information in there. Only I need access to the tasks, but I don’t want them sitting in my tasks taking up space and being irksome, so I tag them and reference it later.
I find that having a project for something like that is a bit cumbersome, so I just tag them =)
I’ve also seen them used for video topics/categories that don’t matter in a project so much.
Oh custom fields, how I love thee…
The staple of our custom fields right now is “Brands” and "Status"
Much like @briankb, where he has fields for products, we use our brands. This helps identify things for reporting, design, socials, website, etc.
Status is used for multiple areas, but mainly design, video production, and web development.
I find these are most useful in a similar use case as @Alexis, where I sort by status so I can see what items are blocked or need updates. You may wonder why I have two very similar items like “Ready” and “Complete” and this is mostly for specific use cases like websites. For those familiar with JIRA, it’s like the difference between resolved and closed. So “Ready” means the task has been marked complete by the owner, status changed to ready, and the next step is for someone (manager, or whomever) to come through and review it and make sure everything is functioning as expected/what they wanted. If it isn’t, they’ll mark it incomplete and change the status to ‘needs update’.
For quick check tasks, it’s not really useful, however for more involved tasks like…a website dev item that is ready for QA, so it might be under “Reviewing” for the duration of the QA, etc.
We also have a custom field for Push Code that we use to note the github branch/code number to deploy, etc. I have found this to be incredibly useful for me, so I don’t have to always hound the developers to comment with it - they just drop it in there as it’s very specific and actionable, then I know what to request for deployment, etc.
I also use fields for things like Priorities of 1/2/3 in some projects, or an order in others. Say we have 15 items and they have to be done in order, I use the numbers 1-15 to order them (while still keeping things like sections for the standard view). This helps me when I have to go and change the order or timeline, also is good for managers to see, etc.
Another interesting thing that came up when I was moving our design team to Asana last month, was that they felt it was helpful to know who had the final sign-off on something.
It’s interesting, because it’s not always the person who is reporting or requesting the item/etc. So for them it was helpful to know who they’re really making it for, if they have questions they can ask them (sometimes it’s not really clear in the collaborator list, etc.) directly in the task, or even just for me so I know who needs to OK it before it’s sent out or used.
I’ve found that it has been helpful in non-design areas as well.
And then of course we have Time and Estimated Time which are pretty self explanatory but have been really really great, as we don’t really want to spend money on another time tracking solution no matter how easily it integrates into Asana (looking at you, Harvest and EverHour!).
And I also use it for things like Zaps via Zapier. So some teams don’t really use Asana, they prefer to stick to sheets for certain things. And with Zaps, it makes it less aggravating =) So for one of our use cases -
- They fill out a form
- Data is captured in spreadsheet that their team uses
- Zap is triggered, creates a task in xyz project with all the information
- THEN, because the team isn’t on Asana, how will they know it’s done? we have a custom field for text entry where they put the link of the completed item (like a tweet or something)
- That custom field entry is another trigger, which then updates a cell in the same row that created the initial task
It’s been REALLY great for things like that. Before custom fields, we had the team’s manager as a member of the project and they would have to go through each completed item to document the delivered asset in the sheet. Now it’s automated!
And finally (This is a beast of a reply), I use fields like “Owner” and “Secondary” for projects like team responsibilities. This is helpful in onboarding, but also just in general for managers or people who are curious. So each team has a primary owner, then a ‘backup’ or secondary person if that owner isn’t available, etc. And that task will describe what they’re responsible for (think design, so things like “Event Imagery” or “Branding Guidelines” would have a task with a detailed description and then a field for owner/secondary).
Anyway, that’s how we/I use those things…I’m sure there will be some evolution =)