How to Sync Jira Versions Across Projects Using Jira Automation

[#1]

Creating a version in Jira once is fine. Doing it three more times? Not so much.

If your teams share a release but work across multiple projects, you know the pain: manual version creation, updates everywhere, and plenty of room for errors.

Some teams avoid this mess by not using Jira versions at all. Instead, they track releases with custom fields or link issues to a “release ticket.” It might work short term, but you end up losing all the native goodness - like filters, dashboards, and automation triggers. In the long run, it creates more complexity, not less.

For mature release processes, a good setup I've experimented combines Jira Plans for tracking, Xray for testing, Golive for environment management (disclaimer: I am the product owner of the Golive Jira App), and the Release Management for cross-project coordination - a scalable, enterprise-ready approach to release governance.

But if you’re not there yet - or just want a lightweight way to sync versions across projects - Jira Automation can cover a lot of ground. You won’t be able to sync everything (like renames or deletions), but for version creation and release tracking, it works well out of the box.

Let’s walk through how to set it up, and finally ditch the copy-paste routine.

---

Solution Overview: Using Jira Automation

Jira Automation is built into the Jira platform and comes at no additional cost on all Jira plans. Just be mindful of the automation rule usage limits, which vary depending on your plan - especially if you're on the Free or Standard tiers. That said, most release-related use cases stay well within those limits.

The concept is straightforward: when a version is created, released, unreleased, or deleted in your master project, a global automation rule can replicate the action across your target projects. This keeps everything aligned - without manual duplication.

Here’s what you can automate

✅ Create versions in other projects when a new one is added in the master project

✅ Release or unrelease versions across all related projects

🚫 Update versions (like renaming or changing dates) can’t be synced - Jira doesn’t offer an "Edit version" action. You can still notify someone to apply the change manually.

🚫 Delete versions can’t be automated either - despite having a “Version deleted” trigger, there’s currently no supported action to delete versions in other projects.

This approach works well for teams where:

• Releases span multiple Jira projects

• Versions drive filters, dashboards, and reporting

• You want to stay lean and avoid paid apps for something that should be easy to automate

In the next section, I’ll walk you through how to configure each rule, step by step.

---

1. Sync version creation across Jira projects

Let’s start by automating the most common part of version management: making sure that when a version is created in your master project, it’s automatically created in all relevant target projects.

How to set it up

1. Go to Jira Settings > System > Global automation

2. Create a new rule:

• Trigger: Version created

• Condition: Project equals [your master project]

• Actions: For each target project, add:
  → Create version
  → Set the name to {{version.name}}
  → Optionally copy over {{version.startDate}}, {{version.releaseDate}} and {{version.description}}

Branch / For each

Unfortunately, smart values cannot be used in the Project field of the "Create version" action, and therefore I was unable to find a way to parse a list of projects. If you find an alternative solution, please share it with us in the comments.

Global Automation

This only works with Global automation, accessible via System > Global automation. Project-level automation rules are limited to a single project and won’t be able to manage versions in others.

Done! When you create a version in your master project, the same version will now be created in each of your target projects.

---

2. Sync version (un)release across Jira projects

Once your version exists across all projects, releasing it in just the master project isn’t enough - you’ll want that status reflected everywhere.

This rule makes sure that when a version is marked as released in your master project, it’s also marked as released in the target projects.

How to set it up

1. Go to Jira Settings > System > Global automation

2. Create a new rule:

• Trigger: Version released

• Condition: Project equals [your master project]

• Actions: For each target project, add:
  → Release version
  → Version name: {{version.name}}
  → Project: [select the corresponding target project]

Want to handle rollback scenarios?

Just copy the same rule again, but with the “Version unreleased" trigger and the “Unrelease version” actions. The setup is identical - it simply reverses the release state across projects.

---

3. Version deletion (notify instead of delete)

Jira Automation includes a “Version deleted” trigger, but unfortunately, there’s no “Delete version” action - so you can’t automatically remove versions from other projects.

What you can do instead

1. Go to Jira Settings > System > Global automation

2. Create a new rule:

• Trigger: Version deleted

• Condition: Project equals [your master project]

• Action: Send a notification
  → Email, Slack, or log message
  → Include version name: {{version.name}}
  → Let someone know it should be deleted manually from other projects

This won’t remove the versions automatically, but it ensures no one forgets to clean them up when needed.

---

4. Version update (notify instead of update)

While you can detect when a version is updated, Jira Automation doesn’t currently support an “Edit version” action. That means you can’t automatically apply changes like name, start date, or release date across other projects.

What you can do instead

1. Go to Jira Settings > System > Global automation

2. Create a new rule:

• Trigger: Version updated

• Condition: Project equals [your master project]

• Action: Send a notification
  → Email, Slack, or log message
  → Include details like version name: {{version.name}} and release date: {{version.releaseDate}}
  → Let your team know the change should be manually applied in the other projects

This won’t sync the updates automatically, but it keeps everyone in the loop - and avoids inconsistencies across your releases.

---

Pro tips and best practices

Here are a few things to keep in mind to make your version sync setup reliable and maintainable:

✅ Stick to consistent version names

Automation relies on matching version names across projects. Define a naming convention and make sure everyone follows it.

🛡️ Limit who can create versions

Restrict Jira version management in your master project to a few trusted admins or release managers - it helps prevent accidental changes.

🧪 Test before going live

Try your rules in test projects first. It’s the safest way to catch issues like missing permissions or naming mismatches.

🔔 Use notifications for edits or deletions

Since automation can’t sync updates or deletions, use “Version updated” and “Version deleted” triggers to notify someone to handle it manually (Slack, Teams, or Jira work item).

---

Final thoughts

Coordinating releases across multiple Jira projects doesn’t have to mean copy-pasting versions or maintaining a spreadsheet on the side.

With a few well-placed Jira Automation rules, you can:

• Create versions once and sync them everywhere

• Ensure release status stays aligned across projects

• Get notified when manual follow-up is needed

It’s not a perfect solution - version updates and deletions still need a human touch - but for many teams, this setup covers 80% of the pain with 20% of the effort.

If your release process is more advanced, combining Jira Plans, Xray, Golive, and the Release Management App gives you the tools to go even further. But even with just Jira Automation, you can already make a big difference.

Have questions, feedback, or a smarter way to handle this? Drop a comment - I’d love to hear how you're managing cross-project versions in your own setup.

[Matt Doar _Adaptavist_]

Nicely summarized, David. And I like that you call out clearly what this approach does not do as well.

[David Berclaz _Apwide_]

Thanks for your comment @Matt Doar _Adaptavist_ 

For DC customers with ScriptRunner, the Version Synchroniser build-in listener can also help here.