Update Feature ID when moved to another product

When you create or copy a feature, its ID is automatically created based on the product code. The ID is a combination of the product code and an auto number (and that is perfectly fine). But when you change the release reference to a release of another product, the feature ID should get a new ID, based on the new product it is attached to. Otherwise, it is confusing when looking at a release or any report/view for people who are across multiple products - features from 1 product seem to belong to the wrong product.

  • Guest
  • Jul 8 2015
  • Will not implement
Release time frame
  • Feb 19, 2016

    Admin Response

    Thanks for the note. We can understand potential confusion when looking strictly at the Feature ID but this is done for good reason.

    If the Feature ID were to be changed, this would break any existing links to the feature (from emails, integrations, etc.). In order to keep all links working properly and to ensure traceability, the Feature ID will need to remain the same.

  • Attach files
  • Guest commented
    July 08, 2015 05:11

    Apparently, it works when you copy a full release, but not when you duplicate a feature on its own.

  • Florian Leray commented
    November 10, 2015 14:17

    Or at least we should be able to update the feature ID manually...

  • Cindy Satero commented
    November 30, 2017 22:30

    Ideally changing feature Id would update links. Jira works in similar way if you change project, the key and associated links are updated.

  • Martin Le Brun commented
    April 03, 2018 22:48

    Dear Admin: you could do like JIRA internally does and keep a history of the old values of the ID that points to the same feature. Then it would not break integrations right?

  • Robyn Diamond commented
    August 14, 2018 21:21

    The admin response above is not justification enough. Other systems support redirects (Salesforce, JIRA, etc) and update IDs when moving between backlogs/queues/etc. 

    Not updating the ID leads to inaccurate reporting & ownership confusion. 

  • Fred Rowe commented
    June 24, 2019 19:52

    The admin response to this should say "This is a shortcoming of the way it's currently implemented, we can't change the feature id because we directly use it for links".  As pointed out by other commenters, other products do this and so can aha, you just need to change the way you're using the ids so that linkages don't depend on something externalized, like feature IDs, and instead rely on internal ids that you manage behind the scenes.

  • John Barry commented
    December 13, 2019 14:34

    Because this doesn't update, I have to reject the feature and copy it and start a whole new feature under the other product.  This should be handled better by AHA

  • Ann Ho commented
    29 Jan 20:15

    This seems like a pretty weak response.  If you treat the feature ID as an attribute and decouple the unique identifier of the item in the back-end from the label, you'd be able to maintain links while supporting this idea.