Many times , We need additional information depending on certain workflow states or other information. Ideally there would be a way for us to have a field that is required after a certain value is set.
Examples -
- On an idea, when we say that something is not under consideration, we need to provide a reason why - There is a field for this, but there is no way to enforce the population of that field.
- On a feature, when an outlook is set to anything other than green, we need a reason why , but there is no way to enforce that policy.
This is fairly critical for my organization as well, and the original poster summarized the use case quite nicely. I will add that as we transition some of our workflow from Jira to Aha, this sort of capability is a glaring gap in Aha where the same functionality is readily available in Jira. In our case, here is the related scenario:
In Jira, field B is required when field A is Yes
We setup parallel fields A and B in Aha, and set them to synch to the same-named fields in Jira
When field A changes to Yes in Aha, and the user leaved field B blank, the push to Jira fails because the validation fails
To maintain data integrity, this ability is an an essential capability needed. For example, when we rollout our features to different cohorts 10-10-10 to mitigate risk. It is important to know when those rollout are both planned and done so that we can evaluate how long it takes for a feature to be available to all customers.
Right now, we must run reports and find out where the rollout dates are missing because they should be populated when the feature's status is changed. They should only be required at that point in time, not any earlier.
Every week, we run reports, ask people to review - very inefficient.
Conditional required fields, similar to conditionally populating fields is essential for efficiencies and data accuracy - especially if wanting Aha! to be the source of truth.