TL;DR
The problem: Jira issue sync silently drops select values that do not exist on the target side, such as “Critical” in one space and “Sev-0” in another.
The solution: value mapping in Elements Copy & Sync pairs each source value with a target value, and its 1:1 mappings keep two-way sync consistent.
Privacy for cross-company sync: a “Selected fields” option controls which fields and values a partner’s Jira instance can see.
Availability: value mapping works with single select custom fields on Jira Cloud, in the Advanced edition of Elements Copy & Sync.
Teams that collaborate through Jira issue sync rarely use the same select values: support rates a request “Critical”, engineering calls it “Sev-0”. Value mapping in Elements Copy & Sync lets a Jira admin pair each source value with a target value, so a cloned or synchronized work item always carries the right meaning. It works between projects and between Jira instances, without changing either team’s fields.
What happens when two teams sync Jira work items but use different values?
Maya leads a support team in Jira Service Management. Her agents rate every request with a Customer Impact field. Raj’s engineering team, at an external partner with its own Jira instance, tracks the same information with a Severity field.
| Maya’s support space | Raj’s engineering space | |
| Field | Customer Impact | Severity |
| Values | Critical, High, Medium, Low | Sev-0, Sev-1, Sev-2, Sev-3 |
| Value after sync | Critical | Empty |
Daniel, the Jira admin, uses an Elements Copy & Sync recipe to escalate requests and keep both work items in sync. Summary, comments and attachments travel across, but Severity stays empty. One Monday, a critical warehouse outage waits two days in Raj’s backlog before anyone notices.
Why doesn’t Jira issue sync carry over select values that don’t match?
A select field only accepts values from its own list of options, so a value with no exact equivalent on the target side cannot be written. Before value mapping, Elements Copy & Sync could not bridge this gap:
| Recipe type | Previous behavior |
| Local recipe (same instance) | A select field could only be mapped to the same field |
| Remote recipe (across instances) | Values were copied only if their names matched exactly, with no warning otherwise |
The usual workaround is one Jira Automation rule per field, which grows with every new option. To see where each tool fits, read when to use Jira Automation, Copy & Sync, or both.
How does value mapping translate one team’s values into another’s?
In the recipe’s Content tab, Daniel opens the three-dots menu on the Severity line and selects Value mapping. He pairs each Customer Impact value with a Severity value, saves the mapping, then the recipe. The step-by-step guide to map values between select fields covers each screen.
| Customer Impact (source) | Severity (target) |
| Critical | Sev-0 |
| High | Sev-1 |
| Medium | Sev-2 |
| Low | Sev-3 |
The next escalation reaches Raj with Severity set to Sev-0, and neither team changed a single field option. You can watch the interactive demo of value mapping to see the same flow on screen.
Does value mapping keep two-way Jira sync consistent?
Yes. When Raj downgrades the work item to Sev-1, Maya’s side updates to High, because each value pairs with exactly one value on the other side. These rules apply to every mapping:
| Rule | What it means |
| 1:1 mapping | Each value pairs with one value, so two-way sync stays consistent |
| Extra values | Values without a counterpart are set to “No pairing” |
| Unmapped values | The target field keeps its existing value |
| Field contexts | Admins add a section for each pair of source and target contexts |
If a sync error occurs, Daniel sees it in the activity logs of Elements Copy & Sync instead of waiting for a report. Each failed field is listed with a plain-language explanation of the error.
Can you control what a partner sees during a cross-company Jira sync?
Yes. Remote recipes now include a Fields option, so Daniel exposes only Customer Impact, Summary and Description to Raj’s instance. Internal fields, such as the customer’s contract tier, stay with Maya’s team. The guide to cross-instance synchronization in Jira explains the broader setup.
| Option | What the remote side can see |
| All fields | Every field and value (default for existing recipes) |
| Selected fields | Only the fields and values the admin chooses |
Where else does value mapping ease collaboration between teams?
The same mismatch appears inside a single Jira instance, for example in support-to-development escalations in Jira. Value mapping covers three situations with single select custom fields:
| Situation | Source values | Target values |
| Same field, different contexts (“Category” in IT and Support spaces) | Hardware, Software, Network | Device, App, Connectivity |
| Different fields in the same instance (JSM to Jira) | Customer Impact: Critical, High, Medium, Low | Severity: Sev-0, Sev-1, Sev-2, Sev-3 |
| Different fields across instances (client to partner) | Client’s select values | Partner’s select values |
Value mapping is part of the Advanced edition on Jira Cloud. Compare what the Standard and Advanced editions include, or see how Elements Copy & Sync keeps teams aligned across projects and instances.
Frequently asked questions
Couldn’t find what you need?
Yes. With value mapping in Elements Copy & Sync, you map a source single select custom field to a different target field and pair each value, for example Customer Impact “Critical” with Severity “Sev-0”. It works between projects in the same Jira instance and between two Jira instances.
Yes. Value mapping applies whenever a recipe creates or updates a target work item, whether for a one-time Jira clone issue action or an ongoing sync. The recipe reads the source value, finds its pairing and writes the matching target value automatically.
The target field keeps its existing value. Elements Copy & Sync only writes a value when the source value has a defined pairing, so an unmapped value never overwrites the target with incorrect data. Values without a counterpart in the other list are marked as “No pairing”.
Value mapping supports single select custom fields. Locked system fields, such as Priority, cannot have different values per space and do not need it. The feature is available on Jira Cloud with the Advanced edition of Elements Copy & Sync, in local and remote recipes.
Key takeaways
- Jira issue sync silently drops select values that do not exist on the target side.
- Value mapping pairs values across fields, contexts and instances, with 1:1 mappings that keep two-way sync consistent.
- “Selected fields” protects internal data when you sync with another company.
Next step: list the select fields your teams sync today and try Elements Copy & Sync free on the Atlassian Marketplace to map them.