Limitations
Last updated
Last updated
Whilst we try to create a seamless integration with Jira Cloud, there is the odd limitation. Often, we are limited due to Jira's APIs, which means that this may change or improve over time, allowing us to address these limitations.
By default Jira makes the Summary and Reporter fields of issues required. This setup is fully supported by Avion, as we can assign the Summary to the card name in Avion and the Reporter to the user that set up the integration. However, further required fields cannot be supported by Avion. Please bear in mind the behaviour related to an .
Team-managed projects use a parent/child hierarchy for the epic/task relationship. This is not the same as the "epic link" functionality used in company-managed projects. Avion would love to be able to make use if this, but unfortunately, the APIs are not currently available. In order to still provide team-managed users with a hierarchy, Avion uses issue linking in Jira to link epics and tasks. If the APIs become available in the future, we will assess the possibility of using the parent/child functionality. It's worth noting that because of this, we do not import existing parent/child relationships in team-managed projects either.
Update: The APIs are now available and Avion has switched over to using epic relationships for team-managed projects. Please note that if you set up an integration with Jira before 13th October 2020, you will need to manually migrate your issues in Jira. .
If you integrate a company-managed project with an Avion story map and change an epic link of a story, Avion will attempt to reflect this in the story map. Ghost cards will be used if the relationship cannot be reconciled.
However, in team-managed projects, this backward-syncing from Jira is not available. Our recommendation is to not use Jira to change your journey, step or release hierarchy. Generally, it makes more sense to alter this in the story map, as you have a much more visual view of it.
During setup of the Jira Cloud integration, a single issue is created and subsequently deleted by Avion. This is used to verify that everything is working as expected. However, an unfortunate side-effect of this is that a Jira key "slot" will be used. So if the last issue you created was PROJ-10 and you setup an integration from Avion to Jira Cloud, the next issue you create would be PROJ-12.