Having a single area path for the entire product doesn't make sense. This value will usually depend on the feature, as area paths define the area of code impacted by a work item. This helps with evaluating code churn and test coverage. It needs to be defined per-feature (and per-story).
The iteration path is akin to a sprint, but could also be broken out by other factors. If Aha sets a feature to the default iteration path, and your team in TFS isn't configured to view that iteration, then the team will never see the work item you created and sync'd over. I'd suggest having iteration path defined on the feature or story, but have it default in a value based on the Release in which it was created.
This can be achieved by setting up multiple TFS integrations for your product.
Through settings, you can set up multiple integrations. For each feature, it is possible to select which TFS iteration you would like to send the Aha! feature to.
That's really NOT a good workaround. We have 146 area paths in our product. Needs to be on the item level.
If each team is assigned to an area path, do I need to create an integration point for each team, if I want the option to send a feature to any area path in TFS?
Thank you! It wasn't obvious that the Integration name could be changed. That's perfect!
Thank you for the note, we will take a closer look at the instructions.
In regards to naming integrations, you can do so by clicking the text at the top of the page (as shown through the attached screenshot)
The integration instructions state:
So as Jonathan says below, this should be updated. Additionally, if I setup multiple integration, when I want to send a Feature to TFS, how do I choose a specific one? There is no way to name the TFS integrations.
Great, I didn't realize you could create multiple integrations per product. You may want to call that out in the Instructions section of the integration or in your blog posts or release announcements on this feature.