Feature Request: Conditional Custom Field Visibility Based on Task Type in Projects

English Forum Product Feedback
, , ,
1

Feature Request: Conditional Custom Field Visibility Based on Task Type in Shared Projects

Dear Asana Team,

We’re using Asana to manage structured research intake and execution processes at our university. Our workflow involves two distinct task types like Program Research and Ad-hoc Requests managed within a single shared project. These tasks follow different information models but share a common approval, subtask, and few other custome fields.

Asana’s custom fields are powerful for standardizing workflows, but today all project-level fields are shown on every task, even when many are irrelevant to that task type. This creates clutter, confusion, and potential for error, especially as we scale and onboard more collaborators.

Use Case Summary

We simulate task types using a custom single-select field called Request Type. Based on this field’s value, we want to display only the fields relevant to that type. For example:

  • If Request Type = Program Research: show Target Term, Credential Type, Competitor Offerings
  • If Request Type = Ad-hoc Request: show Stakeholder Contact, Research Prompt, Historical Data Requested

We rely on Asana task templates to prefill appropriate fields, but since all project fields remain visible after creation, contributors still see irrelevant fields—leading to mistakes and reduced clarity.

Proposed Improvements (What Should Change)

Based on your React + LunaDB architecture and declarative rendering model, we propose the following changes:

  • Extend CustomFieldSetting with conditional visibility metadata, e.g.
    "visible_if": { "field": "Request Type", "value": "Ad-hoc Request" }
  • Update React task detail view logic to render only the subset of fields that meet their visibility condition. This filtering happens on the client side and could piggyback on your existing is_important logic (used in list views).
  • Add a project-level configuration UI that allows admins to define when each field is shown, using existing custom fields (like Request Type) as the controlling variable.
  • Introduce an optional “Show all fields” toggle for admins or power users to override visibility conditions and access full data when needed.

Preserve Existing Behavior (What Should Stay the Same)

  • Backend data model: All custom fields remain attached to the task object regardless of visibility. No change needed in storage or schema.
  • Reporting and search: All custom field values stay accessible for dashboards, exports, API integrations, and search filters.
  • Live sync behavior: Thanks to LunaDB’s reactive subscriptions, visibility updates would still reflect instantly when the controlling field (e.g. Request Type) is changed.
  • Task templates and rules: Continue to use templates to prefill appropriate fields. This visibility logic complements—not replaces—templates.

Why This Matters

This small enhancement would allow us to:

  • Streamline task detail panes for different task types
  • Reduce visual clutter and eliminate irrelevant fields
  • Improve data quality and contributor confidence
  • Scale multi-track workflows without duplicating projects or forms
  • Preserve Asana’s flexible, real-time collaboration experience

We’ve seen repeated community requests for this functionality, and based on our understanding of Asana’s architecture including the React frontend, LunaDB’s declarative data model, and your component-based UI system we believe this feature can be implemented in a lightweight, scalable way.

Thank you for continuing to build a product that supports thoughtful, structured workflows. We would love to see this added to the roadmap.

Bhavika Madhwani

2

@John_Baldo , Im a relatively new user, not sure if this functionality is possible without maintaining 2 projects or multihoming currently and about whats the best approach for this usecase.

Best,
Bhavika

3

Hi @Bhavika_Madhwani and welcome to the forum! Just FYI, @John_Baldo works in the API/programming support area at Asana, not end-user support. But I’m sure others will chime in here on your request. :slightly_smiling_face:

4

Hi @Phil_Seeman , thanks for letting me know :smile:

I also see that there’s a feature in development somewhat related to my use case : the-ability-to-hide-custom-fields-applied-to-a-task-that-dont-belong-to-the-project-in-which-the-task-is-being-viewed/79740/2

I would also like to add to my feature request that if there’s a way in which field level access & visibility(Create/Edit/Read/Delete) can be configured based on user/role , that will be helpful and eliminate the need of multihoming and creating different projects for same use case.

1 Like
5

I’m running into a similar issue. We have a form that folks company wide use to submit items for marketing promo. We’re working to add some more robust workflows, and as part of that I want to add a list of product/initiatives users can select to trigger other rules and to be used for organization. But the full list is quite long (over two dozen items). I’d like it if they could select one of 5 categories, and then have the longer list just display the items for that category to simplify the list for users & reduce confusion.

1 Like