RELATED IDEAS
This idea has been merged into another idea. To comment or vote on this idea, please visit A-I-9965 Require fields by status.
Create conditional required fields
Merged
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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- +3
1
MERGED
Investment Type - Validation Logic
Issue? In an Initiative a user selects the *required Pre-defined custom field 'Investment Type' selection of 'Cap' then the user is required to selects a corresponding pre-defined custom field 'UCMGID', likewise if the user in the Initiative selec...
2
Future consideration
22
MERGED
Conditional / Dynamic custom fields for all and between record types
Ability to configure the values, whether the field is visible or required based on another fields values. Examples: If value of field X = X,Y or X then make field Y visible and make required If value of x field = X then limit values of field Y to ...
0
Future consideration
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.