Allow for Required Fields in Initiative and Feature Forms

We would like to be able to make certain fields within the initiative & feature forms required - so that one cannot save the form without filling out that field. 

We'd specifically like to use this to ensure folks are mapping an initiative to a goal, and a feature to an initiative. 


  • Alex Joachim
  • Jan 21 2016
  • Unlikely to implement
Release time frame
  • Mar 9, 2018

    Admin Response

    As noted, at this time we don't provide required fields on forms throughout the application. We feel that this can be enforced through the organization and do not have plans to enforce this through the UI (in making the forms feel heavier).

    At this stage because the rationale noted above, along with current priorities, we are unlikely to make revisions in this area. We hope you can understand.

  • Attach files
  • Michal Anderson commented
    January 30, 2016 00:21

    I typically hold my tongue when I don't agree with admin responses because I understand the thought that goes into making a decision to tell a client 'no'.  I do appreciate that.

    In this case, I absolutely cannot understand the rationale of not allowing the creation of required fields.  Required fields are already a part of the ideas portal.  I do agree a significant amount of required fields can be counterproductive.  But as I know you all know, just because you tell someone to do something, even if their boss tells them to do it doesn't mean they will. Heck, I'll even give folks the benefit of the doubt and say they'll forget from time to time, or just need to get something in so they can do a report.  Having required fields in any or all of these cases is very important.

    I always tell my teams the thing I hate the most is doing something twice.  So if I need to review every item that goes into Aha to ensure every person has filled out every form correctly that completely defeats the purpose.  I would be fine with defaulting the system to be in a non-required state and heck I'll even take the hit for a field by field setup so it makes me think about how many I really want to do.  But to completely dismiss any thought of having required fields is extremely short-sighted and unfair to those of us who use & administer the product. 

    I ask that you deeply reconsider your decision to completely ax this idea.  I'd even be ok if required fields were only allowed on custom fields.  


  • Deena Cannistraci commented
    August 31, 2016 16:08

    This is critical for managers to obtain proper metrics from the system.  Without allowing clients to determine their own designated required fields to customize our metrics then we cannot get an accurate view of the planned releases using the fields that are the most critical.

    While 'enforced through the organization' is a good philosophy in general, even the best overachievers on the team will accidentally forget to complete a field.  While I'm not a fan of over engineering, I am a fan of systems that allows flexible options to drive the business behavior needed with tools such as AHA.

    Here is an example:

    We are beginning to drive workload management and priority mix for our features within a release.  We have two fields we've created, Priority Mix and Level of Effort.  When our employees accidentally forget to fill this out we are unable to obtain a full overview of our features and adjust .  While I can go back and nag and remind my innocent employee of their mistake of not filling out a field or two on a hand full of features, the best operational assistance I can offer to my employees is to have the system prompt them, right when they are already in the system making the edits to complete the field.  Instead I'm following up, they have to re-work and now two resources are managing innocent and easily made mistakes when the system could have simply prompted the user.


    Having a 'lighter' application is sometimes detrimental to operational efficiencies just as much as too much UI enforcement.  I vote for this to allow the client to determine which fields are required and exactly how 'heavy' they make the form.  

  • Vedran Blazanovic commented
    December 01, 2016 18:57

    I agree, our org could use this capability. I'd prefer to see this as an option for the end user/customer to have the freedom to choose how heavy they make the application based on their specific operational needs.

    Empowering the user to add capabilities, and maybe some heaviness, to the application is not always detrimental to the product's value to the end user. In many cases, it's a value add for their world.

  • Michelle Markosky commented
    July 10, 2017 18:43

    I sincerely hope you reconsider allowing users to implement required fields. Given that Aha integrates with JIRA, which is a tool that does allow required fields, not implementing this functionality can break the integration.

    For example, if someone does not populate a field in Aha that is required in JIRA, pushing that information to JIRA throws an error. The integration between the two tools becomes much less valuable if it's not seemless. 

  • Guest commented
    July 27, 2017 23:59

    This is a potential deal breaker for my team.  As you say, we defined a process to declare certain fields required however since the tool itself doesn't help make this easy we now need extra process.  This is incredibly time consuming and makes this tool less of a tool (i.e., it's not as useful as it needs to be).  I am looking at alternate tools specifically because of this missing feature.

  • Suzie Hastie commented
    August 15, 2017 16:39

    I agree with the other comments posted and would like this to be reconsidered now that a required flag is available for Idea fields, so extending this to other areas is a reasonable request.

  • Jon Lambert commented
    August 31, 2017 21:04

    As this is now available for Ideas I don't understand why it can't be made available for Features and Master Features. There are certain pieces of information that need to be contained in each and while we have many individuals looking at Aha to ensure these fields are populated it still leaves the possibility of things slipping through the cracks. Adding just a few required fields would remediate that potential issue entirely.

  • Guest commented
    January 03, 2018 15:03

    Just adding my vote that this be reconsidered - PLEASE! This is critical to helping us manage our workflow. I appreciate the concern that it will make the form feel heavier - but isn't that a risk based decision for us to make? As we make this decision on the Ideas already, I fail to understand why we aren't given the ability to make this decision for ourselves.

  • Paul Ellis commented
    January 12, 2018 19:56

    I hope you will reconsider. I am confident you can creatively solve for supporting required fields on feature forms without making the UI feel heavier. 

  • Chris Horne commented
    February 02, 2018 20:49

    Not being able to enforce required fields is adding great complexity to our Jira integration... while introducing the need for heavier process control and data quality checking after the fact. Please support required fields to let your customers decide when they are appropriate to use.

  • Rebecca Harwood commented
    February 02, 2018 21:22

    Especially on working with integrations such as JIra, where there ARE required fields and Aha user MUST adhere to those in order to create the item in JIra. Absolutely a necessary option.

  • Kirstin Maurer commented
    March 13, 2018 20:27

    Agreeing with a couple of the more recent commenters - the particular use case we have also relates to the Aha:JIRA integration.  There are some required fields we have in JIRA, that if not entered into the custom fields in Aha, result in a validation error only when the user tries to push/sync the changes.

    While I do see the issue with not wanting to overload the form with too many variables.  (Plus, what if the User is just starting to create a Feature and doesn't have all of the information available yet which might include any "required" fields - this such a validation error might prevent the User from entering/saving the work in progress). 

    Perhaps there could be some other visual prompt that would remind the user which fields are "required" as part of an integration dependency? Either highlighting the fields that are required as part of a successful integration sync (maybe as part of the Custom Field configuration), or putting them into a specific section within the form?

  • James Hvezda commented
    April 12, 2018 15:30

    Agree, with the comments on this thread... in reality is there any form that exists in any system that doesn't have some required fields?  At a minimum, this helps users distinguish what is mandatory vs nice to have at the time they enter the information. Hope you reconsider as the work around (reporting to track compliance) is fairly painful and I don't agree that making a field mandatory would make the form heavier.

  • David Desrosiers commented
    September 19, 2018 01:20

    This is essential for us to maintain data quality.