RELATED IDEAS
Ability to change label names of Standard fields
In our org. we have 2 roles:
1. Product Manager - Who owns the Idea and is responsible for updating idea status.
2. Category Manager - Who should be informed when the idea is updated (Basically a watcher)
The above 2 roles are similar to what the Creator and Assigned to fields can do in Ideas.
Ideas received are processed at multiple backend systems and assigned to a product manager before it is bulk uploaded and the product manager is not always the Creator here.
Category manager needs to be added as a watcher by default to all ideas that will be uploaded and Assigned to is the only field which can do this.
The field names Creator and Assigned to are hence misleading
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- +1
7
MERGED
1
MERGED
Add ability to modify labels for built-in fields
We would like the ability to modify labels for built-in fields such as "Date range" and "Status" so that they can be updated for internal terminology and different use cases. In this scenario, we want to be able to change the word "range" to upper...
0
Future consideration
5
MERGED
Add the ability to change Aha Standard field names
Add the ability to change the Aha standard field names or at least allow the ability to change the display names of the fields. Some of the standard field names don't fit many situations (especially outside tech work) and changing them would reduc...
2
Future consideration
1
MERGED
Ability to re-label or rename standard fields
It would be helpful have the ability to rename standard fields such as the 'Estimates' field to something more natural to our team i.e. 'Story points' This allows our team to use our release planning language for a better UX/workflow
0
Future consideration
This would be really helpful. I get tired of having to explain what an initiative is in a report, when we call them "blue chips". It would be nice to have it be displayed as:
Blue Chip Name
This is a great idea. I'd like to be able to rename 'detailed estimate' to better reflect how we are using this field alongside 'initial estimate' when we are planning.
Please please please support custom display names for out-of-the-box fields.
As other commenters have also shared, there are a lot of very basic, straightforward use cases for this. I have several more of my own. We're working hard as a company to establish shared terminology, as that drives shared understanding and streamlines communication. It would be really great if Aha could reflect that same terminology (whereas instead the slightly different words in Aha lead to confusion and/or slow down conversation). Thank you!
This would be very helpful. The out of box naming for the standard fields isn't always as clear as we would like it to be and doesn't always align to how we are using a given field (e.g. in the example Julie Edwards' gives below). In one example, we want to use the standard 'Initiative' field on our epics layouts, so epics automatically link to the applicable initiative when this field is completed (which wouldn't work with a custom field). However, we might want to name this field something else (e.g. objective) or, for clarification purposes 'Initiatives driven'
Would like to be able to rename the "Release date (Internal)" field and "Release date (External)" to make it clearer what these really means to us as per our definitions and terminology
I see idea A-I-9998 was merged into this one, so just wanted to make sure you know the use case is larger than just the watcher and creator fields. It would be great to be able to change any standard field label.
To give another example, we have two description fields one for technical description that is integrated into JIRA, and one for business description, which is what we use on roadmaps and external communication.
Since "description" is a standard field that cannot be removed, we were face with the following workaround.
Utilize the standard description for either the technical description of business one and create another custom field for the other. That is the option we ended up choosing, but it comes with problems. Our users often put wrong type of descriptions in those field, which causes a lot of confusion and rework.
Add 2 new custom fields for each description type and not use the standard one. This option consumed a lot of real estate space on the record and did not solve for the confusion - users were still using this field mistakenly.
Hope this helps explain more use cases/challenges.
This is an important feedback and needs to be fixed asap as we are planning to launch this to a wider audience within our product team