Skip to Main Content
Status Unlikely to implement
Created by Guest
Created on Jun 1, 2018

TFS Integration, match user for "assigned to" field

Aha! takes my email address as user name but TFS requires <DOMAIN>\<Last Name> as user name. Therefore the integration throws errors when an Aha! user is set in the TFS "Assigned to" field of a feature.

My suggestion to solve this is to

  1. Create checkbox "domain user"
  2. create an extra field for "domain name"
  3. create a field for "conversion rule" with variables

With these options it would be possible to automatically convert Aha! user "" to TFS  user "company\doe", which will be placed in the "assigned to" field of a feature.

    Jun 1, 2018

    Thank you for your idea. It is currently possible to map the Assigned to field to a custom field or to map the TFS assignee to a custom field in Aha! 

    Given that the format of the user name in each TFS setup may be a little different, and the ability to map using custom fields, we are unlikely to implement this idea at this time. We hope you can understand.

  • Attach files
  • Admin
    Austin Merritt
    Jun 5, 2018

    Hi there. The best way to handle this without requiring the additional maintenance you noted above would be to map to a text field. 

    So, in Aha! create a new custom text field (e.g. "Developer assigned") for your features. Then within your integration mappings, map the TFS assignee field to this new custom field. The sync direction would be one way from TFS to Aha! You wouldn't be able to set the value from Aha! to TFS, but it will give you visibility in Aha! of who has been assigned. This has the added benefit of keeping the feature assigned to the PM in Aha! which means it will continue to show up on the My work page for quick access.

  • Guest
    Jun 4, 2018

    Well, as I think about it, the problem with my proposal is that it is likely not to have the same user base in both systems. One obviously has more developers in TFS than managers in Aha!.

  • Guest
    Jun 4, 2018

    Hi, Thank you for your feedback. Well, would be great if you could reconsider in the future.

    I think there are exactly two user name assemblies

    1. domain\user
    2. email address

    Which other assemblies do you have in mind?

    Furthermore does your current solution involve regular maintenance of an additional user list. That's somehow clumsy.