RELATED IDEAS
Associate the same custom field to more than one Aha record type
I've seen this mentioned a few places, but the Aha! staff seems to keep deferring to custom tables as being the answer, which isn't the need.
When I create a custom field - let's say the customer's name or the segment impacted - I want to add it to the Idea, Master Feature, and Feature layouts as I want to:
Minimize maintenance of the set of valid values
Carry forward when one type of record is promoted, merged, converted to another without losing the data
Today, I must add that one custom field to each record type (in the above, I must add to Idea, Master Feature, and Feature), use the same internal reference key, and maintain the values as they evolve.
Both the setup and maintenance would be more efficient and less prone to error and data loss if you can create a custom field and associate it to all relevant record types - similar to how Atlassian and IBM tools manage.
Behind the scenes, with minimal disruption to your UI, you could maintain the same structure - but, update the front-end to allow maintenance in one area to limit the impact.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- +5
2
MERGED
Allow custom fields and their options across data types
The idea is to have a working view where we can rank initiatives and features across our product line and sub products. Ideally there can be a timeline view based on priorities and estimates
1. Product line initiatives
2. Product initiatives
...
0
Future consideration
9
MERGED
Support a master choice list across item types (Goals, Initiatives, Epics, Features, Requirements)
Who would benefit? Organizations who need a common choice list custom field that needs to be referenced and consistent across multiple item types. What impact would it make? This would save time, effort and potential for errors How should it work?...
2
Future consideration
© 2024 Aha! Labs Inc.•All rights reserved
This is my use case (recommended by AHA! support to paste it here for further consideration, as it is a simlat case to the original post):
Ideas holds all values (referring to the custom field of type “Tags field”) and new ones can be added ad-hoc by the user – works now.
Ideas promoted to features carry their values to features – works now.
Once a feature was created by being promoted from an idea, the values of that feature/idea are available for users to select in other features – works now.
Values that exist in Ideas but not in features (i.e. Ideas with these values were not promoted yet to features), are not available for users to select in features – that is what needs to work.
Motivation:
Easiness - the value was already created once in Ideas. The key is the same. It should appear in features, no matter if was never promoted. Same for vice versa – add ad-hoc value in feature should be available in Ideas.
Duplicated/erroneous values – this field holds customer names, both in Hebrew and English. It is prone for typos, spelling mistakes, creating customer names in English and Hebrew, etc.
I use a pre-defined tag field on layouts to help identify dependencies. The same list is used across four different layouts at the moment, so this idea would really help.
It would be really helpful if custom fields were global. We're capturing a lot of financial details and other custom fields on the idea record which I then have to recreate on other Aha records. Some of the custom fields are worksheets with calculations. And if one worksheet has to be modified, I then have to modify it on 2-3 other records. This is time-consuming and cumbersome to maintain.
It simply will save maintenance time since in several cases, I need same custom field to appear in more than one record and currently I need to update in multiple places each change.
This would be very helpful as we have custom fields that appear on multiple record types. A custom field should be global so it can be applied to multiple records and not have to be created multiple times.
This seems like an obvious need. We have a similar issue with a need to capture client names associated with ideas, epics and features. Each time a new client is added we have to manually update 3 different pick lists to make sure we keep them in synch. Custom tables will not work since you can't link the custom table to Jira.
If I could vote this up 10 times I would do so.