nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Microsoft Teams for Jira - the JSM use case and data indexed

Jeff Gibson

We're looking to connect MSFT Team and Atlassian, for the express purpose of our Service Centre providing support via that channel.

The docs for the connected talk about "we're going to copy and index every chat" (sic). Which seems… extreme. I understand that the connecter isn't just for JSM, that it's for Jira in its entirety… but what does the "Chat.Read.All" permission actually grant?

Genuinely ALL chats across our whole Teams tenant?

We just want to be able to use the functionality of converting chats to tickets, and standing-up chats/calls from a ticket. Nothing major, and not intending on letting Rovo loose in Teams. It does seem like this indexing is to benefit Rovo, and is on whether you intend on using Rovo or not…

What are others' experiences? (I've contact Atlassian for more official direction, but I am interested in practical realities.)

Accepted answers

Josh

Hi @Jeff Gibson, I think two different integrations are getting blended here, and the distinction matters for your security review.

What asks for Chat.Read.All is the Microsoft Teams connector for Teamwork Graph / Rovo. It's set up in admin.atlassian.com under Connectors. Atlassian's own page is blunt about it: "By default, the Microsoft Teams connector will index every message in Teams, including private chats and private channels". That covers group, meeting and 1:1 chats, plus public, private and shared channels. The application permissions it requests (Chat.Read.All, ChatMessage.Read.All, ChannelMessage.Read.All and so on) are tenant-wide by Microsoft's definition. During initial setup you can allowlist or blocklist specific teams and channels and limit by date. The date limit can't be changed afterwards. Doc: https://support.atlassian.com/organization-administration/docs/connect-microsoft-teams-to-teamwork-graph/

What you actually need is JSM chat, via the Assist app. You set it up in your service space under Space settings > Channels & self service > Chat > Add to Teams. You add Assist to a private agent team, sign in with Teams, and pick the request types. Then you add Assist to a public team as a request channel. People can turn a message into a request with "Raise a request with Assist", and comments sync both ways. Doc: https://support.atlassian.com/jira-service-management-cloud/docs/set-up-chat-in-microsoft-teams/

As far as I can tell from the docs, chat doesn't require connecting Teams to Teamwork Graph. So you can roll out Assist for the ticketing flow and simply not add the Rovo connector. Have your Entra admin review the consent prompt Assist shows at install, so you're signing off on that app's permissions, not the connector's.

Sami Shaik

@Jeff Gibson ,

@Josh has the split exactly right, and it is worth being precise on the one question you actually asked, because your security team will ask it too.

What Chat.Read.All grants. It is an Application permission, not a delegated one. That means the Atlassian connector reads with its own app identity, with no user in the loop, and the scope is every 1-to-1 and group chat in the tenant, which is why Microsoft requires Entra admin consent for it. Atlassian’s own connector page lists 15 Application permissions in total (Chat.Read.All, ChatMessage.Read.All, ChannelMessage.Read.All and OnlineMeetingTranscript.Read.All among them) and states the consequence plainly: “By default, the Microsoft Teams connector will index every message in Teams, including private chats and private channels.” So yes, all chats, by design. Matthew’s “only the room you connect it to” is how the Assist bot behaves (it is a member of the teams you add it to); the connector is a different thing.

Two facts that soften it, from the same page: at query time “your own Microsoft Teams access is used”, so a user cannot surface through Rovo what they could not open in Teams; and setup lets you allowlist specific teams and channels (editable later) and set a look-back date limit (which “can’t be modified after initial setup”, so decide it deliberately).

For your use case, the review is short:

Install Assist for JSM chat only, as Josh described. Do not add the Teamwork Graph connector. Chat-to-ticket and ticket-to-chat work without it.
In Entra, Enterprise applications, open the Atlassian app that received consent and read its permissions tab. That page, not the Atlassian docs, is what you put in front of your security team: it shows exactly what was granted and by whom.
In admin.atlassian.com, Connectors, confirm the Microsoft Teams connector is absent, and screenshot it for the review file. If someone adds it later, the audit log records who.
If the connector is ever approved, scope it on day one: allowlist the service-centre teams, set the date limit to the retention period your policy allows, and record both in the Data security policy review.

On “practical realities”: the indexing exists for Teamwork Graph and Rovo, and nothing in the JSM chat flow depends on it. Treat them as two separate consent decisions, taken by two different people.

All comments

Matthew Sinclair

off hand - and you may need to talk to the security folks or read the security documents - its only going to index the chat "Room" you connect it too.

Generally speaking the connection is quite literally a member of the room - not server wide.

MS Teams in generally is a real "pain" to us so it's never that "easy" overall.

Also Rovo is more trustworthy than you give it credit for - it's primary mandate is only ever scoped to the user - what you see - it will see. It won't "jump the guardrail" like other AI's.

So if Rovo is indexing - its only for the user and the context of which you ask Rovo.

I'd be more concerned with Co-pilot snooping around to be honest.

I'd suggest using a Sandbox instance and testing what happens - Rovo won't jump the site barrier without expressed permission - and its usually never assumed even if you said "yes" prior. That I've seen happen.

I forgot I wasn't in the sandbox when I asked rovo to grab something - it was confused - when I told it to go get it - it did so after I said where/what/why.

But It won't "remember" that - have to give it permission - at least in my experience.

https://support.atlassian.com/rovo/docs/using-rovo-for-microsoft-teams/

I may be off on a couple of points - but I tend to trust Rovo more so than most AI's these days.

Josh

Hi @Jeff Gibson, I think two different integrations are getting blended here, and the distinction matters for your security review.

Sami Shaik

@Jeff Gibson ,

@Josh has the split exactly right, and it is worth being precise on the one question you actually asked, because your security team will ask it too.

For your use case, the review is short:

Install Assist for JSM chat only, as Josh described. Do not add the Teamwork Graph connector. Chat-to-ticket and ticket-to-chat work without it.
In Entra, Enterprise applications, open the Atlassian app that received consent and read its permissions tab. That page, not the Atlassian docs, is what you put in front of your security team: it shows exactly what was granted and by whom.
In admin.atlassian.com, Connectors, confirm the Microsoft Teams connector is absent, and screenshot it for the review file. If someone adds it later, the audit log records who.
If the connector is ever approved, scope it on day one: allowlist the service-centre teams, set the date limit to the retention period your policy allows, and record both in the Data security policy review.

Jeff Gibson

Ahhh, thank you. Great explanation. We were indeed looking at the wrong thing.

Huge help, much appreciated!

Jeff Gibson

Thanks for the expansion on the answer as well. Great additional context.

We have indeed been looking at the wrong thing. This will make for a much easier convo with our Cyber team!

Sami Shaik

@Jeff Gibson ,

Glad it helped, and thanks for marking it. One thing worth taking into the conversation with your Cyber team: the connector’s permission list on Atlassian’s page is the document to put in front of them, because it is the list Entra will show them at consent time. If the outcome is “Assist only” for now, that is a perfectly defensible position and the connector can be revisited later with a scoped allowlist on day one.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

addon-microsoft-teams

jira-service-management