Allow for Required Fields in Initiative and Feature Forms

This is essential for us to maintain data quality. 

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.

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?

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.

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.

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. 

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.

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.

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.

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.

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. 

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.

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.  

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.  

Thanks!
Mike