Jira's Development panel groups deployment activity on an issue by environment type - Development, Testing, Staging or Production. Azure DevOps for Jira decides which type each Azure DevOps release environment or pipeline stage belongs to, either automatically or through a custom mapping you set up yourself.
This applies to both classic Release pipeline environments and multi-stage YAML pipeline stages.
Automatic matching vs. custom mapping
Automatic matching
Works out of the box, with no setup. A built-in list of common naming patterns is checked against each stage or environment name - matching is on whole words within the name, not the full name only, so "Deploy-Prod-EU" still matches "prod." A representative sample:
|
JIRA ENVIRONMENT TYPE |
RECOGNISED EXAMPLES |
|---|---|
|
Development |
dev, development, local, playground |
|
Testing |
test, qa, uat, sandbox, e2e, smoke, regression, acceptance |
|
Staging |
staging, stage, pre-prod, canary, pilot, beta, demo |
|
Production |
prod, production, live, main, release, master, stable |
This list is intentionally non-exhaustive here - it covers dozens of variations and a few non-English terms. The point to communicate is "common, conventional names are recognised automatically," not the full list.
Custom mapping
Use a custom mapping when:
-
A stage or environment name doesn't match anything in the automatic list - team codenames, client-specific names, or abbreviations that aren't common enough to be built in (e.g. "ClientA-Sandbox", "Ring1").
-
You want to deliberately override what automatic matching would otherwise pick for a specific name.
A custom mapping always takes priority over automatic matching for the same name. If you've mapped a name, that mapping is used - the built-in keyword list is never consulted for it.
Scope
Mappings are set once per Azure DevOps organization (or on-premises collection) - not per Jira project and not per pipeline. One mapping covers every Jira project connected to that organization.
Step-by-step configuration
-
Go to Jira admin settings > Apps > Azure DevOps > Dev Activities in Jira, then open the Environment mappings tab.
This tab only appears once at least one Azure DevOps project is connected. Connect a project first if you don't see it.
-
Each connected Azure DevOps organization has its own card. Click a card to expand it.
-
Add a mapping: click Add mapping, type the exact Azure DevOps stage or environment name, choose a Jira environment type from the dropdown (Development, Testing, Staging or Production), then click Save.
-
Edit a mapping: change the name or type directly in its row, then Save. Save stays disabled until something has actually changed.
-
Remove a mapping: click the delete icon on its row. You'll be asked to confirm - the dialog reminds you the mapping applies to every project in that organization, not just one.
A few things that block Save:
-
A row with a name but no type, or a type but no name.
-
Two rows using the same name (case and accents are ignored when checking for duplicates).
You can map up to 100 environment names per organization. A successful save shows a brief "Saved!" confirmation.
Resolving unmapped environments
How to identify them
Azure DevOps for Jira keeps a short list - up to 50 - of stage or environment names it has seen that didn't match anything, automatically or custom. The next time you open the Environment mappings tab, every one of those names appears as a mapping row with the name already filled in and the type left blank, and a banner above the table tells you how many need attention: "N names need an environment type."
Recommended resolution flow
-
Open the Environment mappings tab and check for the "need an environment type" banner.
-
For each listed name, choose the correct Jira environment type from its dropdown.
-
Click Save. Once saved, each resolved name is cleared from the unmapped list, and any future deployment using that name resolves immediately - no further action needed.
Constraints and edge cases
-
If deployments are turned off for every integration that reaches an organization, new names stop being collected there until deployments are turned back on - the tab shows its own banner for this case.
-
Only the 50 most recent distinct unrecognised names per organization are tracked. Once you're at the cap, further new names won't be recorded until existing ones are resolved and cleared.
-
Mapping changes only affect future deployments - they don't retroactively reclassify deployments Jira has already recorded.
-
A custom mapping matches a name that is exactly the mapped value, contains it as a whole word, or starts with it as a prefix - you don't need to match the full stage name character-for-character, just give it a recognisable word to anchor on.
Contact us
If you have any questions or need help with environment mapping, please contact our Support Team.
Updated: October, 2026