Integrations 2.0 List field mapping is hard with long lists

I would like to add few comments here>

1. the value mapping for JIRA custom field / AHA custom fields can be very very frustrating provided you have long value lists and in my context, when I am trying to evangelize and support AHA usage in our company (we have enterprise licence), this is a real problem as it slows down configurations and it is a source of regular delays. I already had a chat about that with aha support and a meeting where I demonstrated the issue and the deal was to submit new idea - as I found one already, I would like to add my vote for fast-forwarding the delivery.
2. Using "integration templates" is not a solution as when template is used, it can not provide its benefit of reusing the mapping provided that in configured JIRA project there are changes done (e.g. addition/deletion of value from value list) OR when you have different configurations of available values amongst projects in JIRA within the same custom field (e.g. field "country" does not provide devs ability to choose from all countries in every project)
3. There is a simple solution that would solve the situation and I would like to propose:

Quick and easy solution

Create a "Compare string values and map automatically" button to be added to the value mapping window. something like DEV - 0,5 hours, QA - 0,5 hours :-). It should use basic string comparison for automapping values where string matches and leave the others.

Value for customers and AHA users

- removal of constant frustration of admins and users who accepted that they will be manually doing this (I have 3 fields of 20-30 values to map few times a week)

- in some cases, this is really about removing a super poor "admin experience". Just imagine someone having a custom field of 150 values and having them to be mapped directly. I would go mad.

- contribution of faster adoption of AHA tool in companies using that - I can imagine that without me being an aha/tools-freak, our company would already stopped using it as there would be noone willing to constantly do the manual mapping

Long-term solution / maturing of the feature

• to remove this problem in an elegant and more mature way, I would propose to re-think the approach to value mapping conceptually in a way that aha can do more for the user - map everything that can be mapped and provide shortcuts to maintenance of aha fields and solutions for shoulder cases
• e.g. when AHA pulls the values for a custom field, it should offer not only automated mapping, but also offer addition, deletion (set disabled) of values in the aha custom field, something like: 
  • step 1: create custom AHA field of type "list field with auto-mapping of values" 
  • step 2: add value in configuration and set it mapped to JIRA field
  • step 3: click on "configure mappings" for the related fields opens a wizard
  • step 4: wizard shows result of auto mappinng attempt and highlights values that can not be automatically mapped
  • step 5: for each unmapped value, wizards offers solution actions
    • create new value in AHA custom field OR
    • map into some of the existing fields OR
    • keep unmapped (=mapped to a system value in aha custom field that will show as "unmapped")
• I would investigate possibility how to provide regular and automated job that would be reviewing the custom field mapping and will pop-up a message to user when it finds out that value-set in JIRA for an automapped custom field was changed
• I would investigate whether JIRA allows to retrieve not only "enabled" values for a project, but also those that are disabled for specific project including the scenario when they were available and used in JIRA and became disabled. AHA should be able to handle that dilemma retrospectively and autoupdate the mapping configuration and aha custom field values configuration and lists in general