Skip to Main Content
Status Future consideration
Categories Features
Created by Zach Rose
Created on Dec 6, 2016

Unique field layout based on feature type

As we continue to expand our use of Aha, one issue that has come up is that within a given product, there are different types of work/requirements that require different types of information. We're adding more and more custom fields, and it's starting to get to the point where we have way to custom fields for each feature, and most are unused for any single feature.

One possible solution we've thought of is having a custom field layout tied to a Feature Type, so that when a feature is of a certain type, those custom fields are shown in the UI.

Best case solution would also have the type for a given feature be changeable, with all data retained. So, for example, Type A has custom fields 1, 2, and 3 -- a feature starts as Type A with data in all 3 of those fields, but then evolves into Type B, which has custom fields 4, 5, and 6. at that point it would be great to only show fields 4, 5, and 6 in the Feature UI, but still be able to create reports on types 1, 2, and 3, and also if the type was switched back the Type A, fields 1, 2, and 3 would show up in the UI again with the data intact.

  • Attach files
  • Nerissa Muijs
    Dec 12, 2022

    One of our use cases: we’re still trying to figure out how to use epics as milestones, and I’d like to have a layout based on what the PM chooses in the create step. So, they would click add epic, then choose the epic type (milestone/product) and based on that choice they would have specific fields visible on the record.


    I see that this idea is now 6 years old. What is the likelihood that it will even be implemented, even with the amount of votes it has?

  • Byrne Reese
    Oct 7, 2021

    This is especially important when managing an integration with Jira, as bugs and features (tasks and user stories too) often have different field required fields. So in the current implementation, I have to add a ton of custom fields to a feature, even if they are not required for that feature's type.

  • Cody Dulock
    May 22, 2020

    It would be great to have multiple project templates in a single workspace that I could choose from for each "activity". We have multiple types of recurring projects that span mutliple workspaces that have different flows. Adding all possible fields isn't an option for maintaining efficiency.

    We're currently using ClickUp in conjunction with Aha and plan on abandoning Aha if this kind of integration doesn't come soon.

  • Guest
    Apr 26, 2019

    This conditional logic should also be applied to initiatives and other record types. It would give you the ability to clean up the fields a user needs to see depending on what they are accomplishing with that initiative. Having to show all fields even though a user only needs 3 is a poor user experience and leads to bad data. 

  • Jerrold Emery
    Jun 20, 2017

    Please find below 2 use cases to support this enhancement:

    USE CASE 1:

    My product has 2 feature types: Functional and Non-functional features.

    My Functional Features need to have fields on them specific to them, for example, my functional feature needs to show a custom field called “Owner”. This field is used to show the Product Owner driving that feature.

    My non-functional feature needs a field called “Architect”. That is the Software Architect responsible for the non-functional feature.

    Yes, I could use a generic field that serves both, but this is just one example. My non-functional features will have very different fields than my functional features.

    Additionally, the two feature types would have a different workflow. For Example:

    Non-functional features will go from “not started”, to “Started” to “code Review” to “complete”

    Functional features will go from “not started” to “in design” to “in development” to “complete”

     

    USE CASE 2:

    Another example is whether or not the item has User Acceptance Testing and Who that person is. Non-functional requirements will not need UAT or and Assigned Person, I wouldn’t want those fields on those types of requirements if only for the fact that they are just noise.

    While we use Jira to track execution, it serves as a good example.. in Jira, I can create several different types of issues, and those issues have different fields. We have Defect issues and they have certain fields, we have User Story issues that have their own fields, Epics have their own, etc.

    In Aha!, we also have different type of features that are unique in nature, contribute to the same project and product, but have their unique fields because they are in fact, unique.

     

  • Guest
    Dec 9, 2016

    No disrespect ;-) but I'd like to remove the Aha score and Tags field from our feature windows. Is there a way to do this?  We may eventually use Scores but right now it's just confusing folks. Thanks. 

  • +1
21 MERGED

Contextual Custom Fields

Merged
Have the custom fields that appear be based on another field or type. An example would be "Severity" only appearing if the Feature was of type "Bug fix".
Guest about 8 years ago in Features 0 Future consideration