Integrations 2.0: Support importing unmapped issue types

In 1.0 you could map Features to Stories but also set the JIRA integration to support importing unmapped types.

This meant that bugs, tasks, etc created in JIRA could be imported as Features in Aha!

This is important, without this we have no way to visualize bugs in Aha! that were created in JIRA. We need to track bugs in Aha! as part of our planning workflow.

  • Danny Archer
  • Dec 18 2017
  • Shipped
Release time frame 1 month
  • Attach files
  • Guest commented
    December 21, 2017 15:17

    We used to use the 1.0 integration in a similar way in that we could create bugs and have them get imported back into Aha!, and when we would push features into JIRA we could move them to different issue types for better issue visibility at a glance in JIRA for the dev team (User Stories/Non-functional/technical tasks).


    Perhaps this warrants a new Idea, but it would be nice to have support to map stories from Aha! to different issue types in JIRA based on the the type field of the story.

  • Tyler Warden commented
    January 10, 2018 13:38

    It gives us a lot of value to track bugs/defects in Aha! especially for stakeholder reporting as those stakeholders have visibility into the planned release cadence for fixes.  As we work with customer to plan upgrades, visibility into bug squashing is key.

  • John Paul Grippa commented
    January 10, 2018 13:45

    I am having the same issue. This used to work just fine in Integration 1.0. Once upgraded to 2.0, none of the existing non-story type tickets are syncing properly and new Bugs/Support issue with not import. Considering we now handle all prioritization of the backlog, include features, bugs, and support issues in Aha, this has become a serious problem for us.

  • John Paul Grippa commented
    January 11, 2018 14:05

    See for similar existing idea.

  • Matt Wagnon commented
    January 30, 2018 15:53

    The "Enhanced" JIRA 2.0 integration has effectively destroyed our process and ruined the visibility that we once had for our stakeholders in Aha! Without this "Idea".   We currently give stakeholders the ability to self serve and see what is planned for every release.  Customer success teams, Account Executive especially are interested in support issues related to their accounts.  They no longer have this visibility and Aha! is supposed to be the single source of truth for all planned releases, support packs etc...  It no longer can effectively act as that with the JIRA 2.0 changes.  Also Product owners would like to plan from one single place.  It is not an ideal user flow to plan in multiple places based on the ticket type.  Aha is no longer providing us the functionality that we purchased it for and there are now people wondering if we selected the right solution.  We never experienced anything negative from the errors called out in the 2.0 enhancement for the record.

  • David Solow commented
    March 13, 2018 18:59

    This is very important for us - beyond just capturing and visualizing bugs, we parse Enhancements out from Features and definitely need both captured in JIRA and Aha! 

  • Steven Whittington commented
    March 22, 2018 04:21

    Despite a lengthy discussion with Aha pre enabling the 2.0 integration to get assurance that we would not end up with duplicate nor incorrectly updated items in JIRA, like we did when enabling 1.0, guess what.. it's worse.

    Its been a month now and in addition to my day job I get to spend nights and weekends manually clicking more than 31,0000 times to implement the round of feedback I got two weeks ago. Then today, i get different responses from Aha support basically saying that the earlier response is wrong, that the problem is know and won't be fixed. 

    Like Matt's comment below, our product team took a lot of flack in advocating for Aha, the integration was painful, basically every ticket in Jira got duplicated then marked as done... the horrors of that experience made us ultra gun shy in going to 2.0... the reassurance was overwhelming but false. Our engineering team roll around on the floor laughing anytime Aha is mentioned, our Success team are in tears... Our Executive team don't even want to talk about it due to the complete lack of clarity now that there are hundreds of duplicate, releases, initiatives and features in Aha making any reporting a farce.

    Aha without a reliable sync to Aha is an unacceptable business liability and makes Aha a very expensive ideas portal.

  • Andrew Brooks commented
    June 19, 2018 14:54

    We have a scenario where one of our product teams is using both stories and tasks to create a separation between customer requests and internal development tickets. To convert all of those tasks to stories is technically achievable in JIRA, however that level of change is going to be a challenge. I want to be able to import both tasks and stories in a single integration as this will give that Product Manager the total picture of the work outstanding that needs to be completed. At the moment he has half of the picture and its a barrier to adoption.