Asana Custom Fields: Set Up Useful Project Information

Use Asana custom fields for information your team needs to compare, filter or act on across tasks. Start with a small, agreed set: a delivery stage, a request category or a separate requested date. A field is useful when its value changes somebody’s next decision.

Asana’s field organisation guide describes using fields to categorise work and connect it with other project features. This article covers task fields inside projects. If you are still choosing the platform, start with our Asana versus monday.com comparison.

Check the plan and choose the field type

Standard custom fields are available on Starter, Advanced, Enterprise and Enterprise+, according to Asana’s field reference. Formula fields require Advanced or higher current tiers; the formula documentation covers calculations. Do not assume every type shown in the documentation belongs to Starter.

Choose a type around the answer you need. A dropdown prevents several spellings of the same stage; a number lets people enter a quantity without mixing it with prose. Asana’s type guide distinguishes one-choice and multiple-choice fields, numeric values, text and dates separate from the task’s due date.

These are suggested definitions, not built-in requirements. Ask the person who will update each field whether the choices are clear. Keep the brief and explanations in the task description; a growing list of dropdown options is a poor substitute for a useful conversation.

Add the field and decide its scope

In project list view, use the plus button beside the field columns, or open Customize → Fields. When creating a field, enter its title, type, description and any options. Asana’s setup instructions explain both routes.

A local field belongs to one project or portfolio. Adding it to the organisation’s field library makes it global, so it can be reused. Leave it out of the library for a project-specific field. The same scope guidance describes this distinction.

Use a local field while one team is still deciding what a label means. Reuse an agreed library field when several projects must describe the same information. Search before creating another similarly named field; two columns called “Review stage” are not a dependable shared standard unless the team intentionally uses the same field.

Assign ownership before sharing the structure

Asana’s field access levels separate configuration responsibilities. Field admins can rename or delete fields; Editors can change options, colours and formula inputs; Users can use a field without changing its configuration. Review the field’s permission settings when creating it or through its editing window.

Choose someone responsible for the definitions as well as the settings. An option called “Agreed” should mean the same thing to the account manager and delivery team. Record what evidence is needed before selecting it, and who resolves an ambiguous case.

Editing a global field affects the projects using it. Asana also distinguishes removing that field from one project from deleting it altogether. Check the editing and removal guidance before retiring a shared field, and review connected processes first.

Local fields and hidden columns are not privacy controls

By default, people with project access can see its custom fields and values. Asana’s separate private-fields feature restricts access to named members and requires Enterprise or Enterprise+ on current plans. A local field describes where the field is used; it does not make the values confidential within that project.

For the onboarding example, keep ordinary delivery information in the shared project. Before adding information intended for a smaller audience, establish who should see it and check the account’s actual access controls using an appropriate test account.

Make fields useful in day-to-day views

In list view, use the toolbar’s filter or sort control and select the custom field. Asana’s view guide also explains that list and board views can show different fields, with visibility changes saved for that view. Hiding a column simplifies a layout; it is not the private-field setting.

For a review meeting, filter to tasks ready for review. For planning, inspect page estimates and requested launch dates alongside the actual work. If colleagues must open every task to understand the filter result, improve the field definition or the task titles before adding more columns.

Check imported fields before reusing them

Asana’s CSV preparation guide says fields created when importing a new project are local. It recommends converting them to global fields for reuse and matching options exactly to avoid duplicate local fields in later imports.

The importer adds tasks; it does not update existing ones. Do not repeatedly import a corrected spreadsheet expecting it to repair the same tasks. Review the preview, field types and a small sample first. Keep the original export available while resolving mismatches.

Rehearse the onboarding review

Illustrative acceptance checks: create a few clearly labelled practice tasks. These are proposed checks, not results from a hands-on test.

1. Try the definitions. Ask two colleagues to classify the same example and discuss any disagreement.
2. Change a stage. Move a practice task into and out of the review filter and confirm the expected result.
3. Check shared meaning. Add the agreed library field to a second practice project and verify its options before wider reuse.
4. Check access. Confirm who can change the field’s configuration and who can see its values.
5. Inspect an incomplete task. Agree who fills missing information instead of treating a blank value as a completed decision.

For requests arriving through a form, our Asana Forms guide covers mapping answers and reviewing the resulting task. Keep one owner responsible for the fields after launch, and remove administrative steps that do not support a real decision.

Sources reviewed 29 September 2026 against official Asana documentation. The agency example and acceptance checks are illustrative recommendations.