If you follow Rovo updates, you may have noticed a pattern: many customer questions and JAC requests are about the same thing — how Rovo should work when an Organization has more than one Atlassian Site. Recent release notes answer parts of that, but the language is not always easy to line up. Some updates talk about Organization-wide capabilities, others about connected Sites, and the emerging Unit model adds another layer. So cross-Site Rovo is moving forward, but it can still be hard to tell what works today, what comes next, and where the real boundary is.
In this article we look at Units, how they change data boundaries, and what that means for Rovo and the Teamwork Graph.
What Units are
Units are Atlassian’s model for grouping collaboration inside one Organization. They sit between the Organization and Sites.
Each App sits on one Site, and each Site is part of one Unit. Users are assigned to Units, which makes them part of that Unit’s Directory (Team App). Users still need access to each paid App separately.
Managing Units is an Enterprise feature. For Organizations without Enterprise plans, all Sites effectively sit in the same Unit. That means “Org-wide” and “Unit-wide” usually mean the same thing if an Organization only has one Unit.
See What is a unit? and Units: Frequently asked questions for more details.
Eventually…
Each Unit will have its own Teamwork Graph and Unit-scoped Rovo experiences. Rovo Agents can then be shared between Sites in the same Unit, which enables cross-Site access and automations. Chat will also be able to use data from all Sites in the Unit, while still respecting user permissions. MCP OAuth connections will become Unit-aware.
The Team Directory (Team App) will be Unit-scoped. Goals, Projects, and Assets remain available per Site.
There are no details yet on which admin controls will be Organization-, Unit-, or Site-specific.
Result: full cross-Site support inside a Unit, and clearer separation between Units where an Organization has more than one.
The problem
Units are still in EAP, so the platform is in a transition phase. Atlassian product teams work on individual roadmaps and all have their own timelines for making their parts unit-aware.
Where different Rovo & Platform App areas stand today
You may see different behavior in your own Organizations. I checked at least four Organizations and saw differences in all of them. This is my current understanding of each area.
Rovo Search
Rovo Search is already moving in a practical multi-Site direction. According to the cross-Site search release note, users can select up to five Sites in the full-page Rovo Search experience. The current Site is always included, and results show which Site they came from.
Rovo Chat
Rovo Chat is still Site-specific and does not yet use data from other Sites or Units.
Studio App
There is currently one Studio App per Organization. You can switch between Sites inside Studio, and permissions are still Site-specific.
Agents, automations, and apps are managed on the Site where they were created, but they have different cross-Site capabilities.
Rovo Agents
In the Knowledge section, you can limit an Agent’s access to specific apps and spaces. You can also add knowledge from other Sites. This works for read access. I wasn’t able to execute write tools on those other Sites.
The Agent Account overview in the Admin UI is Site-specific. You can give an Agent Account app access to different Sites, so cross-Site knowledge access can work for Agents using their own account as well.
Studio Automation
Studio Automation can work cross-Site. Automation steps, both triggers and actions, are connected to a Site when you add them. For example, you could create an automation on the Sandbox Studio Site and trigger it on the Production Site.
That also explains why not all automation steps are available in Studio yet: each product team has to make its steps Site-aware.
Cross-Site automations may be a workaround where an Agent tool cannot execute the cross-Site action directly.
MCP and the Teamwork Graph
With the recent release, the Teamwork Graph tools read_teamwork_graph and write_teamwork_graph in MCP can now work across the Organization instead of being limited to one Site. This is shown as “Works across organization” during consent and in audit logs.
My interpretation of this: Identity does not yet support Unit-scoped OAuth. For most Organizations, all Sites effectively sit in one Unit anyway, so Organization-wide and same-Unit access usually mean the same boundary. The cross-site feature was more important than waiting for all puzzle pieces to come together for Unit-scopes in MCP.
MCP Controls already cover multiple levels: Organization admins can turn MCP toolsets on or off for the whole Organization. With Atlassian Guard, they can also block MCP on an app level, which effectively means blocking it for a Site is possible. Blocking individual tools at Site level through Guard policies is not available yet.
Other Platform Apps
I see different behavior for the Teams app across the Organizations I can access. For some, Teams is Site-specific. For others, it is already Organization-wide, presumably as preparation for making it Unit-scoped.
Artifacts rolled out on a Site-level. Goals, Projects, and Assets also exist per Site.
Overview: Current vs. target stage
This table shows the experience we’re seeing today and the goal Atlassian is working towards. Cells I’ve marked with * are based on my assumptions and what I know today. Not everything is super clear yet.
Area | Current stage | Target stage |
|---|
Units | Not rolled out broadly yet | Default: one Unit for everything; Enterprise can have multiple Units |
Teamwork Graph | One Teamwork Graph per Site | One Teamwork Graph per Unit |
MCP | Mostly Site-specific; Teamwork Graph tools are Organization-wide | Unit-aware MCP |
Rovo Search | Search across up to five connected Sites | Unit-wide search |
Rovo Chat | Site-specific | Unit-wide access |
Studio App | One app per Organization, with Site-specific management | Per Unit-settings* |
Rovo Agents | Site-specific accounts; cross-Site knowledge access; Site-specific tool execution | Shared across Units*; knowledge & tool execution within Unit |
Studio Automation | Can work cross-Site | works cross-Site within Unit* |
Artifacts App | One per Site | One per Unit |
Directory (Team App) | Org- or Site-scoped, depending on the Organization | Unit-scoped Directory |
Other Platform Apps | Goals, Projects, and Assets are available per Site | Remain Site-based |
OAuth and identity | No Unit-scoped OAuth; Guard works Organization-wide | Scopes match Units and Sites; Users are mapped to Units as well as Apps |
Summary
The goal is quite clear: Units will be the new boundary for the Teamwork Graph and therefore enable Cross-Site Rovo features in all experiences. The road there will stay bumpy. Different Product Teams have different timelines and we’ll work with that in-between-state for a while. As different Organizations are on different rollout schedules, this gets even more confusing, especially if you manage multiple Orgs.
