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!

[Tomislav Tobijas · Accepted solution]

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

[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

[Rustem Shiriiazdanov _Actonic_ · Accepted solution]

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 

1. Create a custom field f.i. “Found in (Main Release)” = Select list (single choice)

2. Set its context to apply to all customer projects (and relevant issue types).

3. 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

[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.

[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.