Map story states

Sync up the states in Avion with the states in your backlog tool for a powerful planning to delivery workflow.

When you set up your integration, you will be able to map your Avion story states, known as Workflow, to your backlog tool states. The mapping screen will look like this.

This is something that can be changed after the integration setup is complete in the configuration panel. This is great, as it means you can scale your story maps and processes as your team develops and matures.

The term "states" mean slightly different things across different tools, so here's the rundown.

ToolWhat does Avion identify as states?

Jira Cloud / Data Center

Issue statuses. Not board columns (although this can be easily mirrored)

Azure DevOps


Board columns

GitHub Projects

Project columns


Pipelines (columns)

Remember that in Avion, you can completely customize your Workflow, and your story states in Avion don't need to match your backlog tool. For instance, you could do the following:

Notice how the planning states in Avion don't need to be duplicated in Jira. The idea here would be that stories are only generally pushed to Jira when they are Ready for Dev, but on the occasional instance where a story is pushed earlier than this, it still lands in the Backlog state in Jira.

Secondary state mappings

If you end up with states in your backlog tool that are not mapped to an Avion state, you can optionally define these on a secondary state mapping. For instance, in the following setup:

The Rejected state has not been mapped as part of the required state mappings. This means that a pushed story will never land in Rejected. Equally, changing the state of a synced story in Avion will never result in that being in Rejected in Jira.

However, if someone moves a synced story to the Rejected state in Jira, Avion will update that story to In Review in Avion. Cool eh?

Secondary state mappings need to be configured after the initial integration setup and can be changed at any time.

Last updated