People working in both Aha! and Azure DevOps (ADO) modify the "Iteration" field found on user stories and bugs in ADO.
As releases solidify, some work items may no longer be planned to be included, and new ones may have been added.
Updating the iteration for a work item that needs to change which release it's in creates double-work for people to ensure the work items reflected are accurate to what's going to be shipped.
Multiple teams and application repos exist in a single project area in ADO where hierarchy/levels of iterations are used to keep them sorted and readable.
Root project iteration
Example Iteration App1
Nested iteration
Example App2
Another nested iteration
The existing Release <--> Iteration integration available in Aha! only works for iterations directly under the root project area.
Dual effort in whichever system, ADO or Aha!, was not used to keep work items aligned to the appropriate iteration/release.
Using the release to iteration sync as it stands now results in the parent iteration being created in Aha and features being placed there instead of the release name nested under that level. Otherwise, you lose the readable and organization of the nested iteration structure as all iterations for multiple applications/teams live at a single level.
The work item in "Nested iteration" from the example above would sync the release of "Example Iteration App1" to Aha! and place the work item on that release.
One can make a custom field to house the iteration value from DevOps and select the lower hierarchies - my idea is to allow this same selection to be used when setting up the release integration so the curated structures of iterations in ADO are what's used for the work item's release in Aha!