So, Teamwork Graph Connectors (fka as Rovo Connectors we think?) are touted as the way to bring all-important context to AI, specifically context from outside of the Atlassian ecosystem.
We index it all! You can search it. You can chat with AI about it! You can even write AI Agents that reference it.
[Huh, you know it's funny… I kind of recall there was another product that promised to index all of your data, including Confluence (because we all know how Confluence search has historically been less than stellar.)... Now what was other product called? Oh yeah, Glean. More on that later…]
So yeah…. That's the promise:
Rovo: Enterprise search across all of your data + context for AI stuff. Oh wait I mean Teamwork Graph.
Whatever.
Not everyone should see every piece of data. If you've got a performance review between you and your boss, that shouldn't come up in a search that somebody else does.
The team working on a super secret skunkworks project may not be ready for everyone in the company to read about it.
Oh no! So does that mean we can't have this?
Well, no. Atlassian has "solved" this problem by making sure everyone logs into these various Rovo/Teamwork Graph Connectors with their credentials, and then they know what search results you should be allowed to see (because they also index the permissions for various data.)
Ok whew, that's good. But wait. What if somebody has not logged in to the connectors?
Well, I regret to inform you that they see… Jack Squat:
No literally. If somebody searches Rovo for a document that exists in Sharepoint, but has not authenticated the Sharepoint connector, the results are empty. Here's an example where a user searches for policy docs that definitely exist, but has not yet connected. We've even filtered for "Sharepoint" docs:
But wait Darryl, the answer then is that everybody just needs to connect their Sharepoint. And their Slack. And their Outlook. Everybody as in all 6000+ of my users. (Oh sure, that scales.)
Here's the thing:
Glean didn't require this. Instead, Glean asked Admins "Ok, we know not everyone should see everything, but is there an "All Employees" group where if someone is a member of that group, and a doc is visible to that gorup, then that result shows up? Yes? Cool.
And does that cover a MASSIVE amount of documents? YES.
So yeah, I don't know why Atlassian doesn't do this. They certainly could've "borrowed" this security model from Glean. I dunno. Perhaps it wasn't robust enough to pass certain certifications or something.
By the way, this was asked before by @Brian Lysy but I don't know if the answer there is actually clear enough:
At the time Arkadiusz Wroblewski wrote:
Also, make sure you have personally authenticated your account within Rovo so it can pull your individual SharePoint permissions at runtime.😬😉
That would solve the problem for Bryan, but not for all of his users.
So, let's talk about Agents. What spurred this whole article for me was that my user had previously built an Agent in Glean that connected to Slack. It wasn't perfect (the Slack integration was… not great), but it could at least read the correct policy documents in Sharepoint and answer questions based on them.
To see if we could transition off of Glean, we created a Rovo Agent that referenced the same Sharepoint documents. It worked great… for me. But not for the user. At least not until I walked him through going to a Rovo Search page and clicking on the [CONNECT] button that overlaps and obscures the "Microsoft Sharepo" filter:
But without that, the Agent churns for a while and ultimately comes up empty. Very disappointing, as it renders the Agent effectively useless (and worse misleads anyone who uses it who is not authenticated with Sharepoint).
The aforementioned agent's details are pretty simple:
You are the T&E Policy Assistant. Your role is to answer employee questions about travel and expense policies ONLY using information from the two official policy documents here in Sharepoint:
Global T&E Reimbursement Policy (March 1, 2025)
Global T&E Policy FAQ Supplement (September 1, 2025)
And here's what happens when a user who has not authenticated with Sharepoint uses said Agent:
So yeah... that's not great.
I don't know if Atlassian can really fix this without rearchitecting how Connectors work. But yeah, it kind of sucks.
[Yes, I have talked to Atlassian about this - including talking to some a PM or two at Team 2026 who said they were aware of the issue but uh… I don't think they had figured out a fix yet. Sads.]
@Darryl Lee I agree that the user flow isn't ideal (but when is it ever). Users are getting pushed to add a connection, even though the connection isn't setup by the admin. On the other hand they are not notified to connect once the connection is established in the Org.
I do like that Atlassian is quite conservative with permission handling and usually does not require a centralized authentication. These connections are a pain in the butt and cause issues more often than not.
OH! I forgot! My clickbait title mentioned "Teamwork Graph" not just Sharepoint. So allow me to highlight this:
We in fact have installed Connectors for Microsoft SharePo... (sic) as well as Slack and Lucid and Asana and OneDrive (same connector as SharePo...) and Outlook Calendar and Outlook Mail and Airtable and Docusign.
But yeah, users won't see results from ANY of those applications in their Teamwork Graph / Rovo until they click Connect for each of those.
That's 9 Oauth Connect workflows that 6000+ of my users will have to go through.
I don't know how many applications you have, or how many users, but that's a lot of connections to have to be made.
Good times, good times. :-D
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
😂😂😂 For those who don't know @Darryl Lee the energy that he embodies in person comes through in his writing... "OH! I forgot! My clickbait". I'm not sure if Atlassian would have to rearchitect how Connectors work but even if they do this is a pretty significant hurtle that would warrant it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Darryl Lee
I think you found another good candidate for JAC :)
Btw. i flied over documentation and they don´t look consistent about wording so thats confusing.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.