Ability to have a choice field (custom) that integrates TWO WAYS with Azure DevOps
Right now we have a choice field of Yes/No/Not Set, but we are unable to integrate it back/forth with Azure DevOps. Not sure why it's being limited with Azure DevOps has the same choice fields. Please open up the integration so we can keep our fea...
We are still having this existing issue when attempting to map the same predefined choice list between Azure and Aha. Any idea as to when this will be fixed? Our goal is to have as much relevant information flowing between the two tools for visibility from both product and dev.
FYI, I've been working with Aha support on this issue because it still didn't work for us following Nathaniel Collum's post. Turns out, it still does not work for those using the "XML process model" in Azure DevOps, only for those using the "Inherited process model". At the suggestion of Aha support, I've created a separate idea for this specific case: https://big.ideas.aha.io/ideas/A-I-10579
attempting to post the attachment again it appears to have failed.
we have a field called Shipping Version that we map to a like field in ADO called Shipping version. Unfortunately, due to the delimiter in a choice list
ADO uses a ; to have multiple values and Aha uses a , for multiple values and it doesn't play nice together. see example the Shipping version is set through Aha the WFM shipping version is set in ADO.
Thanks for the feedback on this idea!
It looks like we already support syncing Aha! choice list with ADOS choice lists (see below).
However, I see that Priority and Severity are standard fields that you cannot yet map to choice list options. Are these the fields you are trying to map to? If not, please let me know if there are specific fields that you're unable to map to so that we can better understand this use case.
If you are trying to sync a custom choice list in ADOS to a custom choice list in Aha! and it's not working for you, please reach out to us at firstname.lastname@example.org.
We are in need of this functionality also. It is limiting us with the flow of information from ADO which results in either a lot of manual effort to correct the data format or we just end up having to ignore it, which is de-valuing the integration.
I agree with Tessa. This is becoming huge pain point while you starting using AHA in more advanced and customize way.
We are stack with few very important for us fields
See also this duplicate request: https://big.ideas.aha.io/ideas/A-I-8840
Updating this to mention that this has become more of a pain point the more we use Aha. It seems like an implementation oversight that fails to deliver on the promise of "two-way sync" with Azure DevOps (aka TFS). Due to this limitation, our only option is for custom Azure DevOps fields that are synced with Aha to be read-only on the Azure DevOps side.
For information that needs to sync both ways, we are stuck using tags, which makes reporting harder since we can't easily enforce consistency and we're overloading the tags field with a bunch of different types of information.