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
  • Guest
    Reply
    |
    Jan 23, 2024

    As others have said, for different kinds of work that the team use Aha for, it would be ideal to be able to have different layouts (and custom fields) depending on type (eg a New Feature type might need different fields than a Bug Type).

    It seems strange that the use case of having different fields by Status exists (a much more niche use case to me) - this absolutely basic functionality of different layouts by Feature Type does not.

  • Paddy Corry
    Reply
    |
    Jun 1, 2023

    This would be very useful for a scenario I'm investigating related to a Feature Workflow.

    Go To Market work can be relatively small in size and scope compared to Features, so are not currently captured on the feature workflow. But... they are really valuable, because they unlock Feature value by getting them onto the screens of different customers, and getting their feedback.

    I would love to make that Go To Market work more visible on our Features workflow to facilitate planning conversations. The custom layout for a GTM work item could be much more lightweight than our Feature layout.

    Also, as an Aha administrator, when I see the text 'Feature and requirement templates can be created per type.' in the workflow config screen, it does imply to me that this 'unique field layout based on feature type' feature is already possible. At least, that's how I read it : )

  • Nerissa Muijs
    Reply
    |
    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
    Reply
    |
    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
    Reply
    |
    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
    Reply
    |
    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
    Reply
    |
    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
    Reply
    |
    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. 

  • +2
1 MERGED

Allow different configurations for different Feature Types

Merged
Who would benefit? Anyone using multiple feature types. What impact would it make? More flexibility in the setup and use of custom layouts. How should it work? When configuring a custom layout, allow the layout to be applied to a specific Feature ...
Guest 7 months ago in Features 0 Future consideration
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 over 9 years ago in Features 0 Future consideration