Hi everyone, We have a Jira setup with one main project and multiple customer projects. Our initial idea was that customers could report bugs in their own projects, and then we would be able to clone or move those issues into the main project. As part of this process, we want customers to indicate in which version of the main project the bug was found. Ideally, we would like to use a Version Picker field that displays the versions from the main project. However, we have encountered the following limitations: * The Version Picker field can only show versions from the same project, not from another project. * Copying the versions from the main project into each customer project is not a viable option, because customer projects already have their own versions and we want to avoid duplication and inconsistencies. * We would like to avoid Jira Marketplace apps and rely only on native Jira capabilities (we are using Jira Enterprise). Given this context, we would like to ask: * What native Jira options exist to reference or select versions from another project? * Are there recommended approaches using custom fields, automation, issue linking, cloning, or workflows to solve this scenario? Any ideas or best practices would be very helpful. Thanks in advance!

Hi @Asier Vadillo , As you've discovered, versions are tied to a specific space in Jira. There's a feature request for being able to pick a version from another space: JRACLOUD-66760: Ability to pick Version from another Project As for some workarounds, you could try to use: * Cross-space releases in Jira Plans (Premium and Enterprise feature) > personally, I would check this first. I've tested it once or twice so I'm not an expert. The thing with this is that you can only visualize cross-space releases in plans, and not on work items directly 👀 * You could use automation to copy versions from one space to another > now, this works, but it would depend on your business process and cluttering you've mentioned. * Potentially... you could create a custom field (e.g., a single-select list) in customer projects that manually lists the main project's versions. This field would need to be updated manually or via automation when new versions are added to the main project. I'd say that this doesn't probably align with best practices... In this scenario, I would even recommend using a text field, which would be read-only and just use automation to 'pull' the main space version name into it. So, you don't have any other bottlenecks when it comes to copying versions/releases or maintaining list fields, but just displaying version name (if that's viable) 🤔 I'd definitelly try Jira Plans first and see if this could fit the requirement you're having. Hope this helps. Cheers, Tobi

Hi @Asier Vadillo As mentioned by @Tomislav Tobijas Atlassian has a request to make cross-Project version picker, but so far we have to work with some workarounds. Just want to add a few details in addition to Tomislav's solutions: 1. Atlassian documents a pattern where Automation calls Jira’s REST API to append a new option into a dropdown field context. And Jira Automation supports triggers like “Version created / updated / released”. So you could probably try to combine these to achieve the goal if the Jira Plans won't work. So you will need to Create a custom field f.i. “Found in (Main Release)” = Select list (single choice) Set its context to apply to all customer projects (and relevant issue types). Create an automation rule in the main project: Trigger: Version created (or use Version updated if you also want to react to edits; Atlassian notes Version updated listens broadly). Action: Send web request to Jira REST API endpoint that creates an option for that field context: URL format shown by Atlassian: .../rest/api/3/field/{fieldId}/context/{contextId}/option (you can find it in API docuemntation) 2. Totally not questioning your business process, I'd consider option to reduce number of customer projects if the only purpose they are created for is to track customer requests. So if it's just customer isolation, then JSM Organizations + request participants can handle that natively reducing the version headache to minimum (you will only need to care about creating cloned/copied versions in a single JSM project). 3. Also the pure exotic approach could be to create a separate project where automation will create issues named like "version ABC" etc, and let customers link these pseudoversions to issues in their projects, but that is not something i can recommend as that is defenitely not a good practice (not sure about customer isolation in that case too, as that will require quite a delicate approach to permissions). Regards, Rustem

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to reference versions from another project in Jira?

Asier Vadillo

Hi everyone,

We have a Jira setup with one main project and multiple customer projects.

Our initial idea was that customers could report bugs in their own projects, and then we would be able to clone or move those issues into the main project. As part of this process, we want customers to indicate in which version of the main project the bug was found.

Ideally, we would like to use a Version Picker field that displays the versions from the main project. However, we have encountered the following limitations:

The Version Picker field can only show versions from the same project, not from another project.
Copying the versions from the main project into each customer project is not a viable option, because customer projects already have their own versions and we want to avoid duplication and inconsistencies.
We would like to avoid Jira Marketplace apps and rely only on native Jira capabilities (we are using Jira Enterprise).

Given this context, we would like to ask:

What native Jira options exist to reference or select versions from another project?
Are there recommended approaches using custom fields, automation, issue linking, cloning, or workflows to solve this scenario?

Any ideas or best practices would be very helpful.

Thanks in advance!

Accepted answers

Tomislav Tobijas

Hi @Asier Vadillo ,

As you've discovered, versions are tied to a specific space in Jira. There's a feature request for being able to pick a version from another space: JRACLOUD-66760: Ability to pick Version from another Project

As for some workarounds, you could try to use:

Cross-space releases in Jira Plans (Premium and Enterprise feature) > personally, I would check this first. I've tested it once or twice so I'm not an expert. The thing with this is that you can only visualize cross-space releases in plans, and not on work items directly 👀
You could use automation to copy versions from one space to another > now, this works, but it would depend on your business process and cluttering you've mentioned.
Potentially... you could create a custom field (e.g., a single-select list) in customer projects that manually lists the main project's versions. This field would need to be updated manually or via automation when new versions are added to the main project.
I'd say that this doesn't probably align with best practices...

In this scenario, I would even recommend using a text field, which would be read-only and just use automation to 'pull' the main space version name into it. So, you don't have any other bottlenecks when it comes to copying versions/releases or maintaining list fields, but just displaying version name (if that's viable) 🤔

I'd definitelly try Jira Plans first and see if this could fit the requirement you're having.

Hope this helps.

Cheers,
Tobi

Rustem Shiriiazdanov _Actonic_

Hi @Asier Vadillo

As mentioned by @Tomislav Tobijas Atlassian has a request to make cross-Project version picker, but so far we have to work with some workarounds. Just want to add a few details in addition to Tomislav's solutions:

1. Atlassian documents a pattern where Automation calls Jira’s REST API to append a new option into a dropdown field context. And Jira Automation supports triggers like “Version created / updated / released”. So you could probably try to combine these to achieve the goal if the Jira Plans won't work. So you will need to

Create a custom field f.i. “Found in (Main Release)” = Select list (single choice)
Set its context to apply to all customer projects (and relevant issue types).
Create an automation rule in the main project:
1. Trigger: Version created (or use Version updated if you also want to react to edits; Atlassian notes Version updated listens broadly).
2. Action: Send web request to Jira REST API endpoint that creates an option for that field context:
  - URL format shown by Atlassian: .../rest/api/3/field/{fieldId}/context/{contextId}/option (you can find it in API docuemntation)

2. Totally not questioning your business process, I'd consider option to reduce number of customer projects if the only purpose they are created for is to track customer requests. So if it's just customer isolation, then JSM Organizations + request participants can handle that natively reducing the version headache to minimum (you will only need to care about creating cloned/copied versions in a single JSM project).

3. Also the pure exotic approach could be to create a separate project where automation will create issues named like "version ABC" etc, and let customers link these pseudoversions to issues in their projects, but that is not something i can recommend as that is defenitely not a good practice (not sure about customer isolation in that case too, as that will require quite a delicate approach to permissions).

Regards,

Rustem

All comments

Tomislav Tobijas

Hi @Asier Vadillo ,

As for some workarounds, you could try to use:

Cross-space releases in Jira Plans (Premium and Enterprise feature) > personally, I would check this first. I've tested it once or twice so I'm not an expert. The thing with this is that you can only visualize cross-space releases in plans, and not on work items directly 👀
You could use automation to copy versions from one space to another > now, this works, but it would depend on your business process and cluttering you've mentioned.
Potentially... you could create a custom field (e.g., a single-select list) in customer projects that manually lists the main project's versions. This field would need to be updated manually or via automation when new versions are added to the main project.
I'd say that this doesn't probably align with best practices...

In this scenario, I would even recommend using a text field, which would be read-only and just use automation to 'pull' the main space version name into it. So, you don't have any other bottlenecks when it comes to copying versions/releases or maintaining list fields, but just displaying version name (if that's viable) 🤔

I'd definitelly try Jira Plans first and see if this could fit the requirement you're having.

Hope this helps.

Cheers,
Tobi

Rustem Shiriiazdanov _Actonic_

Hi @Asier Vadillo

Create a custom field f.i. “Found in (Main Release)” = Select list (single choice)
Set its context to apply to all customer projects (and relevant issue types).
Create an automation rule in the main project:
1. Trigger: Version created (or use Version updated if you also want to react to edits; Atlassian notes Version updated listens broadly).
2. Action: Send web request to Jira REST API endpoint that creates an option for that field context:
  - URL format shown by Atlassian: .../rest/api/3/field/{fieldId}/context/{contextId}/option (you can find it in API docuemntation)

Regards,

Rustem

Olliver Ordell

We have struggled with (almost) the same issue for years.

I solved this by prompting Cursor to create a CLI tool to synchronize Releases across Spaces via the API. It took ~1,5 - 2 days, and then it worked, without me writing a single line of code my self.

I love the future.

Rustem Shiriiazdanov _Actonic_

@Olliver Ordell quite a good take. We're using Claude Code (Max subscriptions) ourselves in CLI mode for so many things nowadays. A year ago I'd say vibe coding is nonsense, but now it's something our teams are using constantly for multiple tasks.

Asier Vadillo

Hi @Tomislav Tobijas

It is hard to say that the only viable option of the 3 is the custom field one. We need to see the releases in the work items and we can not copy our releases to the other projects because they have their own.

Thanks for the answer!

Asier

Asier Vadillo

Hi @Rustem Shiriiazdanov _Actonic_ ,

Will check if the custom field option from Tobi with your approach 1 met our criteria.

Thanks a lot!

Asier

Rustem Shiriiazdanov _Actonic_

Hi @Asier Vadillo

sounds cool! Should you have enough time later, please also tell us us which solution will actually work for you, I am really curious about it.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud