Why Can't Rovo Search Across My Atlassian Sites? [Champions Slack Insider]
This discussion started with a question from @Darryl Lee that catches many Enterprise customers off guard:
If our JSM is on a different site (but in the same Atlassian organization) as our Jira site with Rovo, isn't there a connector for it? If Enterprise supports multiple sites, shouldn't Rovo be able to search across them?
Short Answer
Generally, no.
Today, Rovo experiences are primarily scoped to the Atlassian site where they are configured. Content, agents, and search results are governed by site boundaries and permissions.
While Atlassian continues to expand capabilities through Teamwork Graph, connectors, and MCP, there is currently no native "search all sites in my organization" experience.
Why This Feels Confusing
Part of the confusion comes from the user experience itself. Several Champions observed that search menus sometimes display Jira sites, sandboxes, and restored environments, while other sites may not appear in the same way.
Because Jira Service Management is built on Jira, many users reasonably assume:
If Jira is searchable, JSM should be searchable too.
At the time of this discussion, it wasn't clear whether this behavior reflected a product limitation, a rollout difference, or simply a user experience inconsistency.
The result is a search experience that can feel fragmented, especially in organizations running multiple Jira, JSM, and Confluence sites.
The Real Enterprise Challenge
The discussion became more interesting when the conversation shifted from search to knowledge management.
My initial response to Darryl was that there are ways to approximate a unified experience:
- Use MCP and APIs to pull information into a Rovo-enabled site
- Mirror key information through automation or webhooks
- Use integration or data platforms as a bridge layer
None of these create true cross-site Rovo experiences, but they can help organizations work around some of the limitations. Later, @Rebekka Heilmann _viadee_ surfaced a real-world example that highlighted why this matters:
Main Site
- Corporate Confluence
- Centralized knowledge
- Standardized Jira projects
Business Unit Site
- Jira Service Management
- Dedicated knowledge base
- Independent teams
The business-unit teams wanted to use Rovo to create knowledge articles across both environments.
The challenge? Rovo does not currently provide a native mechanism to automatically bridge knowledge and actions across separate Atlassian Cloud sites, even when those sites belong to the same organization.
In other words, the exact limitation Darryl identified in search was now creating operational challenges for content creation and knowledge sharing.
Can MCP Solve This?
That naturally led to the next question:
Could Atlassian's MCP Server be used as a bridge between sites?
Rebekka proposed connecting one site to another through MCP and allowing an agent to create content across environments. The idea is clever, but a challenge quickly emerged.
Atlassian's Remote MCP Server uses OAuth authentication, and actions execute with the permissions of the authenticated user; that means:
- Actions run as the logged-in user
- Permissions are inherited from that user
- MCP does not currently provide a native shared cross-site service identity
In practice, the workflow becomes tied to an individual's identity rather than a centrally managed organizational account. This doesn't make MCP unusable, but it does introduce governance, ownership, and support considerations that many enterprises will want to avoid.
Could Forge Be a Better Approach?
Another interesting suggestions came from @Ciara Twomey Nielsen, who proposed using Forge instead of MCP. Forge apps can run in two different execution contexts:
- asUser — actions run using the permissions of the current user
- asApp — actions run using the permissions granted to the application itself
For cross-site scenarios, asApp can be appealing because it avoids tying the workflow to a single person's credentials. That can make governance, ownership, and long-term support easier to manage. In theory, a Forge app could:
- Read content from one Atlassian site
- Create or update content on another site
- Act as a bridge between otherwise separate environments
However, there are trade-offs.
The Drawbacks
Forge doesn't magically make Rovo cross-site aware. You still need to:
- Design and maintain the integration
- Handle permissions carefully
- Manage app scopes and security reviews
- Account for differences between sites
Content formatting can also become challenging. Macros, embedded content, links, and site-specific configurations don't always transfer cleanly between environments.
In other words:
Forge may be the cleaner architecture, but it is still a custom solution rather than a native cross-site Rovo capability.
What This Tells Us
The interesting takeaway from both the MCP and Forge discussions is that customers are trying to solve the same underlying problem:
They don't want separate AI experiences for separate sites.
They want AI to understand their knowledge, requests, and workflows regardless of where that information happens to live.
Today, Forge, automation, APIs, and MCP can help bridge some of those gaps. But they are all workarounds for a capability many Enterprise customers increasingly expect to exist natively.
Was this helpful?
Thanks!
Dr Valeri Colon _Connect Centric_
2 comments