Rovo in Microsoft 365: connecting the right Teams and Outlook context to Jira work

Britta Neugebauer [yasoon]

Atlassian recently announced a significant step for Rovo in Microsoft 365: Rovo is available in Microsoft Teams and Microsoft 365 Copilot, while Jira Cloud for Microsoft Teams can use Rovo to interpret natural-language requests.

At yasoon, we like where this is going. We have spent years working on the assumption that people will continue communicating in Microsoft Teams and Outlook, even when their work is managed in Jira. Asking everyone to choose one ecosystem was never particularly realistic. AI makes the relationship between these ecosystems even more interesting.

Rovo should be able to use context from Jira, Confluence, Microsoft 365, and other connected tools to help users understand and act on work. In Teams, users can ask Jira to create, update, or assign work in natural language. Atlassian has also introduced a Microsoft Teams connector that can make conversations and meeting context available through Teamwork Graph.

That is quite a step beyond sending Jira notifications into a Teams channel. But it raises a question: does better AI simply need more context, or does it need the right context?

The race for context

Atlassian’s Teamwork Graph, Microsoft’s Work IQ, and ServiceNow’s Context Engine reflect the same idea. The names vary, but the core idea is the same: AI works better when it understands the people, projects, and decisions behind a prompt.

An agent that knows only the summary and description of a Jira work item understands less than one that also knows the related project, dependencies, documentation, decisions, and conversations.

However, anyone who has worked in a large organization also knows that a lack of information is rarely the only problem. There may be several versions of the same document, old email threads that contradict current documentation, multiple Teams conversations about the same topic, and meeting transcripts containing both decisions and ideas that were later discarded.

More context is not automatically better context. The challenge is shifting from "How much information can the AI access?" to "Which information is relevant to the work it is trying to understand?"

Creating Jira work from Teams is only the beginning

With Rovo and Jira Cloud for Microsoft Teams, conversations can become Jira work without somebody manually copying the details. That is useful, but creating the work item is only the beginning.

Further feedback may arrive via Outlook, while Engineering discusses implementation in a separate Teams thread. The scope is revised in a meeting. Two months later, a new owner needs to trace the reasoning behind the decision.

The challenge is not getting every Teams message, Outlook email, and meeting transcript into Jira. It is knowing which communication belongs to which work.

With Microsoft 365 for Jira, we approach this by creating explicit relationships between Microsoft 365 communication and Jira work. Teams conversations, Outlook email threads, and meetings can remain connected to the relevant Jira work item as the work develops. Templates, Presets, and automation help teams manage how those communication workflows are used.

This behaves like focused context layer between Microsoft 365 and Jira. It does not try to reproduce the entire Microsoft environment inside Atlassian. It answers a narrower question: which Microsoft 365 communication is relevant to this Jira work?

What if AI already knew where to look?

Consider asking Rovo to improve the description of a Jira work item. If a Teams conversation, an Outlook thread, and a meeting are explicitly associated with that item, those relationships can provide more focused context than a broad search across everything the user can access.

This creates an interesting direction for Rovo Skills, Actions, and standards such as Rovo MCP. An app could make selected, issue-related communication available to an authorized agent when needed. That can support workflows such as summarizing the communication around an Epic or turning agreed meeting outcomes into follow-up work.

One context graph for everything?

We do not expect every organization to move all its Microsoft context into Atlassian, or all its Atlassian context into Microsoft. Each platform has different data, permission models, products, and requirements. Many organizations will continue to operate across both ecosystems.

That makes a multi-platform context landscape more realistic than one universal context layer. Microsoft understands communication and work happening in Microsoft 365. Atlassian understands work managed across Jira, Confluence, and its wider platform. The interesting challenge is moving the right pieces between those environments when they are needed and permitted.

Rovo in Microsoft vs. Microsoft 365 for Jira: where is the difference?

Rovo can understand a Teams conversation and turn it into Jira work. Microsoft 365 for Jira also supports workflows that connect Teams and Outlook with Jira.

The difference is what happens around the Jira work. Rovo brings AI-supported search and actions into Microsoft 365. Microsoft 365 for Jira keeps selected Teams conversations, Outlook emails, and meetings associated with the relevant Jira work item as the work continues.

The two approaches can therefore be complementary. Rovo helps users act on context. Microsoft 365 for Jira helps create and preserve relationships that make that context more relevant.

Better enterprise AI is not about giving an agent access to everything. It is about giving it the right context for the right work at the right moment.

Disclosure: I work for yasoon, the company behind Microsoft 365 for Jira.