Configurable destination of imported features
As a product manager, I should have control over the destination of where imported features and epics go so that they are in the release or parking lot where they belong. Today, the destination of imported items seems almost up to chance although there seems to be a pattern in going to the next upcoming release. One has to go looking for the imported items immediately after import so as to file them away appropriately. (When Integration 2.0 for TFS was released last week, imported items were going to the very first release ever, but someone seems to have changed that since then.) I don't think it makes sense to define the destination in the integration definition because releases and parking lots are dynamic. To that end, I tend to think that the user would need to define the destination each time they import so they can choose from the options available at the time.
| Release time frame | 3 months |
-
ADMIN RESPONSEJul 25, 2024
Integrations will now respect a workspace's "Default release" setting when importing records from integrations (either automatically or manually).
4
MERGED
Set a Jira Integration to a Default Release or Parking Log
Our organization does not use Releases within Jira. This causes an issue since when an Epic/Feature is created in Jira it defaults to the furthermost left release. It would be great if I could instead default these to a parking lot instead. We hav...
0
Shipped
14
MERGED
Allow User to select Release for new Import Candidates in Integrations 2.0
Our company uses different fields for Aha Release than the Jira Fix Version, so when new candidates appear in the Import Queue in Aha, we need the ability to be able to pick and assign a Release for the record(s) upon import.
If no release is ass...
0
Shipped
15
MERGED
Select the Release for Integration Updates
Every Feature belongs to a Release but when importing from Integration Updates, you can't choose which Release to import to. I understand that in this section, only Features that have been synced between systems should appear, but any net-new Feat...
0
Shipped
14
MERGED
Integrations - Import to a defined release
As an integration user with integration with TFS and AzureDevOps it would benefit me to have the ability to assign all imported items to a default release for imports. The systems I am importing from do not do releases so I cannot match the iterat...
0
Shipped
1
MERGED
Azure DevOps Integration: new features should go to parking lot
Current behavior: new features that do not have an iteration set in Azure DevOps (root iteration) will be assigned to the left-most release in the Aha board. This means any new features added in Azure DevOps ends up assigned to a release without t...
0
Shipped
© 2025 Aha! Labs Inc.•All rights reserved
I agree that having this be configurable would be ideal.
We're using the integration to map Aha Releases to Azure DevOps Iterations, and because of that, we're able to avoid this issue in a way. The default Iteration (which is the name of the Azure DevOps project) is what we're using as a "parking lot" in Aha. At least it's a known place where new items go into, and then they can be sorted to other Releases (or Iterations) later. Of course this means that any Releases or Iterations you're making you want to have synced between Aha and Azure DevOps.
I am interested in having Parking Lot in sync with Aha/Azure DevOps integration as well.
So , What can be done to make sure that imported data goes to Parking lot and not into Release directly when bulk import is done.
Just being able to specify a default landing area (i.e., one of the Releases in the Parking Lot) would be a big step in the right direction.
Being able to configure it at the integration level as a default if there is no fix version would also be good.
I would agree that this makes sense when integrated into a development software. Having a default of where to put a new feature will help lessen confusion about where it lands.
I agree
Agreed with parking lot.
I have seen this same behavior. In my case, I also had related master features assigned to a specific release. A more reasonable default behavior would be to put the imported feature with the master feature (if it exists) or just put everything in the parking lot.