Multi-tenant Azure DevOps integration with Jira (per-space setup) 🔀

[Tomislav Tobijas]

Hi everyone,

I’m exploring a setup where a single Jira instance is used to manage multiple clients, with separate Jira spaces (ex. projects) per client.

The requirement is:

• Some Jira spaces should be connected to our own Azure DevOps tenant

• Other Jira spaces should be connected to clients’ Azure DevOps tenants

• The goal is to enable the Development panel integration (commits, PRs, etc.) per space + specific automations

So effectively, we would need space-level connections to different Azure DevOps tenants within the same Jira site.

From what I understand, the official Azure DevOps for Jira app does not support simultaneous connections to multiple tenants.

I’ve also seen that some Marketplace solutions might support this kind of setup, but I’m not a Microsoft/Azure DevOps expert and don’t have deep experience with DevOps integrations in general—so I may be missing something.

My question:

• Is this type of multi-tenant integration possible in Jira today?

• If not with the native Atlassian app, are there Marketplace apps that support this kind of setup (project-level tenant separation)?

I've drafted some visuals/flowcharts together with Rovo, so I'm curious if I'm understanding this correctly or not 👀

Any guidance, corrections, or real-world experiences would be greatly appreciated.

Thanks,
Tobi

[Alex Ortiz]

@Tomislav Tobijas have you checked out GitKraken?  I believe it should be able to handle this for you.

[Tomislav Tobijas]

@Alex Ortiz yeah, it's either them, Appfire or Move Work Forward for solutions that I've seen. I would even test it out if setting up multiple Microsoft tenants wasn't such a pain...

It's currently mainly theoretical from my side, so I was wondering if anyone has any experience with this before I move forward to setting up environments and actually testing this hands-on.

[Bryan Guffey]

@Tomislav Tobijas I would reach out the companies and ask them if they've done it. I'm sure GitKraken has, and they'd be happy to tell you all about it and what the risks are!

[Tomislav Tobijas]

@Bryan Guffey true that. Might just reach out to them and see what they have to say 👀

[Gabriela Costa _Appfire_]

This is a supported use case for TFS4JIRA from Appfire. In both TFS4JIRA Self-Hosted and Cloud Native, you can set up multiple Azure DevOps connections (for different ADO instances/orgs) and then configure each sync profile to use the appropriate connection.

If you’d like to try it out, you can find the app on the Atlassian Marketplace here .

[Nicholas Bouchard]

Two questions to clarify what you're looking for here:

First, do you have access to ADO tenants owned by your clients? No matter what integration solution you use, you'll typically need *some* level of permissions, so that may be an obstacle to consider.

Second, do you need a two-way sync? Some integrations only push data in one direction (i.e., from ADO to Jira or Jira to ADO), while others sync data back and forth (e.g., updating data in a Jira work item updates ADO and vice-versa). If you only need a one-way integration, then a platform like Zapier could do the trick, since it can automate actions like creating new work items or queuing a new build. But if you need to automate a complex sequence of actions, integrations like Zapier might not be the go-to.

Unito has integrations for Jira and ADO that let you connect multiple ADO tenants to the same Jira project, and filtering rules make sure work items don't end up scattered in the wrong tenants. They're two-way integrations, so data gets synced back and forth between ADO and Jira.

I hope this helps! Let me know if you have other questions; we write about other integration platforms extensively on our blog so there's probably quite a few other options, too.

[Tomislav Tobijas]

Thanks for the insights and thoughts, @Nicholas Bouchard 

To answer some questions:

First, do you have access to ADO tenants owned by your clients? No matter what integration solution you use, you'll typically need *some* level of permissions, so that may be an obstacle to consider.

That's a yes - development will be done by the main team. The only question is where they will store the code > either in their own org/tenant or in the client's tenant. In any case, the same/similar users will have access to all tenants that require connecting.

Second, do you need a two-way sync?

I'm still not sure about this one. Definitelly it's ADO to Jira, but there might be cases of the other way around. Although that's something we will need to explore and check what the actual requirement is when it comes to that area of integration.

But it's a good idea to optionally check Zapier, n8n, or these kinds of integrations (even if they will be simply through REST APIs).

In any case, these gave me something to think about, so we'll explore those options as well.

Thanks!

[Nicholas Bouchard]

No problem! Yeah, tools like Zapier can handle automation in either direction, so they're a popular first choice for this kind of use case. Good luck in your search!

[Kevin Yorston]

Hey there @Tomislav Tobijas ,

I’m Kevin from Exalate.

This is exactly the type of environment Exalate was built for. While standard integrations often link an entire Jira site to one Azure tenant, Exalate provides a much more granular approach. Since it works at the project level, it gives you a lot more control: Project A can talk to Client X, and Project B can talk to Client Y.

Because these connections are separate, you get the isolation you’re looking for. Each client connection is essentially 'sandboxed,' ensuring there’s absolutely no data overlap between different tenants. This allows you to manage project-level syncing for Client A and Client B independently, giving you full control over what stays private and what gets shared.

Regarding the Development Panel (the UI sidebar with commit counts), Exalate focuses on the deep synchronization of issue data and logic. While populating that specific UI panel across multiple external tenants might require a more specialized approach, if your main goal is driving automations and keeping client workflows in sync, Exalate handles that natively.

I'd be happy to show you how that project-level syncing looks in practice if you'd like to see a demo!

[Tomislav Tobijas]

Hi @Kevin Yorston ,

Thanks for the info! We'll also add Exalate to the list of potential candidates for this integration. While I don't have a specific timeline, we'll probably test whatever is out there and see how each app behaves based on the client's requirements.

Our team has used Exalate before, although for some other use cases, but we're fairly familiar with what's possible and how to use the app.

One note from my side - if you work for Exalate > Marketplace vendor, as per partner guidelines, I'd recommend reaching out through the Partner Portal to get that community profile lozenge, so it's clearer to other users that you're working for the partner company 👈

Thanks again for the insights.

Cheers,
Tobi