Custom fields vs. Tags


#1

When I started getting to know how to use Asana I found myself getting confused about when to use custom fields vs. tags. I notice this coming up quite a bit in the community, so I wanted to hear your thoughts about it. When do you use custom fields and when do you use tags?


How do I use custom fields and tags?

Custom fields

  • I use custom fields to add clarity to a specific project and monitor the type of work I’m doing. Specifically, custom fields become especially valuable when I want to group, prioritize, and sort tasks. That said, the same custom field can be applied to multiple projects, which can be super helpful.

  • My custom fields aha moment: When I sorted a project by custom field! It was a work tracking tool I didn’t know I needed but now can’t live without! As you can see here, I viewed my project by a custom field for priority. I can now see all high priority tasks left to do. In this example I could also search by my custom field for “blocked?” to see if any of the work in the project has roadblocks.


Tags

  • I use tags to track one-off things that span across projects. In a given project I’d rather use a custom field, but tags are really powerful when I want to track a specific bit of information across a lot of different pieces of work or work that might otherwise be disparate.

  • In this example I use a tag to note if a customer is a candidate for an event I have coming up. I don’t want to use a custom field that will live long term in the task, instead I just want to make a note for a unique event that is finite, not long term.

Excited to hear how you use these features!


Featrue Request: Colored Tasks
#2

The first use case we found for Custom fields in Asana was for a Bug list that will be available to anyone working with us.

We are leaving the three custom fields that cam with the Template “Number of User reported, Priority, and Browser” and adding two of our own “Product” and “Does it Effect” which are both drop down lists.

“Product” shows a list of our websites/apps

and “Does it Effect” show a list with options

I would like a better name for “Does it Effect” but it seems clear on the form when a non-technical person is trying to add a new Bug report for us to review later. I’m hoping we can create some type of alert when a new bug is enter with any Does it Effect field is selected that is Red. Those bugs need immediate attention. I also hide all but our own two custom fields on the Task List but all show up on the Edit Task form.

I see using Custom Fields when you need to make sure your team is using the same terminology like in our case a product name.

I see using tags, much like you are using them, for one offs and more general keywords to help you narrow down a search. For now I don’t have a defined set or use for tags but I think we will as we use Asana more for daily task management.


#3

Custom fields are my favorite topic as of late!

Tags

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.

"Templates"
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.

"Meeting Notes"

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.

"Finance"
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.

Custom Fields

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 follower 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 -

  1. They fill out a form
  2. Data is captured in spreadsheet that their team uses
  3. Zap is triggered, creates a task in xyz project with all the information
  4. 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)
  5. 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 =)


#4

Your post has a lot of great tips but this one will save me some time trying to figure out an easy mashup between asana and github.

Thanks for sharing @Caisha


#5

You’re welcome! It’s just one of those small quality of life things that I’ve found to be really really helpful.


#6

Is there a way to see all Custom Fields and all Tags? When selecting Custom Fields I don’t see all fields and have to at least a fragment of the Field name to find it. Am I missing something?


#7

Newer to Asana and had the same question. Why use a tag over a custom field and vice versa. I’m actually seeing it create a lot of confusion for my users as they don’t understand why to use one over the other. We like how custom fields are easy to setup and allow quite a bit of flexibility for predetermined values for users to easily access and select.

With tags we feel the are not as easy to use because you can’t choose from a predetermined value list. We do love how you can click on a tag within a project and then are taken to a page that shows you all tasks that fall under that tag. I think if we could do this on custom fields we essentially would never use tags.


#8

We use custom field values for attributes that are relevant within a project, and tags for attributes that are relevant across projects. For example, within a grocery list project I could assign each task (item) a custom field value of “Produce,” “Frozen,” etc., to sort by custom field and organize my list into sections of the store. But there’s no other project in which those values are relevant. However, lots of projects might have things I need to buy. I could assign tasks across many projects a “buyme” tag, and then favorite an advanced search for everything with that tag to create a master shopping list. There’s no reason I’d do an advanced search for all tasks with custom field value Produce, since they’re all in one project already.

To put it another way, a given tag could apply to any task in your entire Asana world, whereas a custom field value typically only applies in the context of one or more specific types of projects. A custom field is usually “Choose the one best answer to this question about this task,” and tags are usually, “Pick all the adjectives that apply to this task, even if they have nothing to do with each other.”


#9

Is there a way to ensure that if we set a custom field in one project that users of another project don’t have access to that custom field. For example, we may use sensitive information on one team in the custom field drop down (like a special technology, etc) that we may not want everyone to see.


#10

We have a Product Life Cycle that we follow when developing qualifications for the education sector. We use custom fields in our template to track tasks against each stage of that life cycle:

It’s incredibly useful for advanced searches, where we can see the progress of multiple projects at once and get a sense of the sub-teams’ capacity. We also have fields for cost and time, which means we don’t have to spend money on integrations like Harvest.

We never use tags at all. Custom fields do everything we need.


#11

Hi @Michael_B - at this time privacy settings such as these are not available with custom fields. However, we’ve noticed customer requests like these and have made note of this suggestion. Thanks!


#12

Has anyone used tags vs custom fields for editorial calendar?
Honestly struggling here. Your comments are helpful though I still have a roadblock.

I just started using the Social Media Calendar Template. We have topics that we would like to block out for a month’s time, where we want our social posts focus on those features/products. This is essentially a broad look at our calendar. I started creating tags for these and now moved to custom fields.

The thing is that if there are specific social campaigns for these topics, I don’t know how/if I should use custom fields or tags. Originally I wanted a custom field for which social channel it would be. My worry is that if I have a campaign that has an Instagram story + FB post + other channel, that that calendar day would look crowded.

How can I have one calendar and project that will show me specific tasks + broader topic range over time?


#13

Thanks Craig for the simplest and excellent use case description for Custom fields and Tags - and whilst this goes opposite to the official Asana use (.e.g temp for tags), Tags are for global organising/filtering, whilst custom fields are specific to projects. In our company we use them exactly in this fashion. For example we have found useful:

Custom field: Customer Priority (L, M, H) - specific to customer project context.
Tags: Dev Roadmap Priority (L, M, H) - across many projects we do to track and identify the product roadmap elements and the priority in that world view.
eg some tasks at customers are very important to them, but they may not be important in our global product roadmap.