RELATED IDEAS
Introduction of further customization user permissions
It would be wonderful if Aha! had the option to customize user permissions when it comes to adding or editing ideas, adding or editing features, etc. For example, one user could have permission to only work with requirements while not having the opportunity to work with features. This idea could be extended to customization opportunity for all aspects of the Aha! platform.
1
MERGED
Permissions to set per record type in Aha!
Ability to edit an Initiative, regardless of the workspace the Initiative is associated with. However, only want the ability to Edit the Initiative and this access should not apply to Features or other Aha elements.
Ideally, a user can only edi...
0
Future consideration
This would help us out, I want to restrict the users that can promote ideas to Features but at the same time have a team of people who are able to update features and capture requirements. The current solution for user management doesn't allow for this and isn't granular enough, I can only restrict the option to create features by removing the ability to edit features totally, which for us doesn't work with our resource and team structure, I have BA's and a Product Team, BA's work in the requirements, product team manage the backlog, features, priority and the promotion of ideas etc.
This would be extremely helpful to the product team, as we would like to give access only to the Ideas area for our Support and Services team to help manage Ideas prior to our team moving them forward as a feature.
This is absolutely critical for us. Our customer success team is the first line of engagement around gathering requests, building requirements, and fleshing out Ideas. Our product team then takes these Ideas and promotes to Features as part of the regular roadmapping process. We need to be able to assign specific users (or ideally user groups) to determine what actions they can perform on which objects (Ideas, Features, Epics, etc.) It would be even more valuable if we can configure these types of entitlements down to the field level (what fields can a given user/group read/write/update for a given object, layout, etc.)