You’ll benefit from agreeing upon and documenting (in Asana, of course) your organization’s preferred custom fields for org-wide usage.
These should include commonly-used fields, but there’s utility in enumerating all (even more seldom-used) available custom fields you’ve vetted that may come in handy. Perusing this list when you create new workflows and projects may help to remind users of missing or helpful fields they hadn’t consider and will certainly increase consistency.
An efficient way to document these available custom fields is in a project like this, widely accessible in your org:
The task title is the custom field name followed by the custom field description, both of which come from the custom field definition itself. The columns are the actual custom fields that we’re documenting (meta self-documenting alert!). By valuing only that custom field related to the row, it makes it easy to read. You can click any single-select dropdown to browse the option values that make up each custom field.
Some additional best practices:
Use organization-wide (not specific-to-project-only) custom fields for all of these (and in general). They enable advanced searches based on their values, permit multi-homed tasks to share a common custom field value across projects, and lead to increased consistency.
Avoid using Asana-provided custom fields directly because they can’t be customized. Instead, one time only, create your own versions of those Asana-provided custom fields that you intend to use and include them here (see Priority/Importance in the screenshot for an example).
This post is one of several Forum Leaders tips I’ve contributed related to custom fields. See the others here:
I really like this idea of centrally documenting an organization’s custom fields.
The only potential issue I see with your suggested design is in my experience many organizations have more than 30 global custom fields, and you can only have 30 columns in a project’s list view.
For more than 30 custom fields, I recommend using another project(s) for less commonly used custom fields, or split by some other meaningful grouping to your org.
Another alternative is to show, after the top 30, those less common fields in the task detail pane. That offers up to 60 fields (via multi-homing to a second project where you define the second batch of fields).
What an inspiring post @lpb !!!
Never thought about this idea to collect the information about CFs and I think it is totally aligned with having an “Asana mindset”.
And also like @Nao_Kumazaki and @Andrea_Mayer I love the “Progress Bar” one.
Hi, how did you create the colour boxes within the progress bars - I’ve only been able to create a clear box using the word insert symbol option and pasting that into the asana text field?
Is the progressbar auto updated? In Monday they have it as a field that shows for exempel the progress of how many subtask is done. But it sems like i need to update thins one manuell?
Is it possible to hide certain fields from certain people in a project task? For example, we want to create fields in the task, but do not want the installers to see the quote cost field.
All fields within a project will be visible to task members. However it is possible to set up two projects with certain custom fields that the members of the other project cannot see.
How to do it:
Your quote cost field would need to be:
a local field in the project, i.e not added to the library
added to a project which is private or a team that is private; eitherway not public to the organisation or to the members that you do not want to see the quote cost field.
So in your current project A, which you share with everyone, do not place your quote cost field in it.
Instead, set up a private project B with the quote cost field. Multihome all tasks in Project A to project B and setup a custom rule to automatically do this from now on (need Business or Enterprise tier).
The result:
If you (or members of project B) open a task in Project A, you will see the quote cost field in the task’s details only.
If a member of Project A (who doesn’t have access to Project B) opens a task, they will not see the quote cost field in the task’s details (as long as the field is never added to the library!).
I recommend to also test the above between two members, to best understand who sees what.
