# Map story states

When you set up your integration, you will be able to map your Avion story states, known as [Workflow](https://help.avion.io/docs/story-map/workflow), to your backlog tool states. The mapping screen will look like this.

<figure><img src="https://3578170569-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LL6HR00hwiJJav4pLph%2Fuploads%2FnMHTs86dRTO7iSJ2raN2%2Fstory-states.jpg?alt=media&#x26;token=1620982c-2e3b-4b48-b4e9-a05e2a8bd525" alt=""><figcaption></figcaption></figure>

This is something that can be changed after the integration setup is complete in the [configuration](https://help.avion.io/docs/integrations/backlog-tools/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.

<table><thead><tr><th width="233">Tool</th><th>What does Avion identify as states?</th></tr></thead><tbody><tr><td>Jira Cloud / Data Center</td><td>Issue statuses. Not board columns (although this can be easily mirrored)</td></tr><tr><td>Azure DevOps</td><td><a href="https://learn.microsoft.com/en-us/azure/devops/boards/work-items/workflow-and-state-categories?view=azure-devops&#x26;tabs=agile-process#workflow-states">Workflow (work item) states</a></td></tr><tr><td>Trello</td><td>Board columns</td></tr><tr><td>GitHub Projects</td><td>Project columns</td></tr><tr><td>ZenHub</td><td><a href="https://help.zenhub.com/support/solutions/articles/43000206560-customizing-workspace-pipelines">Pipelines</a> (columns)</td></tr></tbody></table>

Remember that in Avion, you can completely customize your [Workflow](https://help.avion.io/docs/story-map/workflow), and your story states in Avion don't need to match your backlog tool. For instance, you could do the following:

<figure><img src="https://3578170569-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LL6HR00hwiJJav4pLph%2Fuploads%2FYyhwpHrJDwqf4om2nx1p%2Fstory-states-2.jpg?alt=media&#x26;token=085df144-274c-403d-a0d9-6431f24d2b9b" alt=""><figcaption><p>A planning + delivery workflow</p></figcaption></figure>

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:

<figure><img src="https://3578170569-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LL6HR00hwiJJav4pLph%2Fuploads%2Fh9eoGchASx88xWmzarGs%2Fstory-states-3.jpg?alt=media&#x26;token=1e6fc0b9-210a-4232-afec-f7d2eb9b8395" alt=""><figcaption></figcaption></figure>

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.