JSM Customer + Rovo + SharePoint

[Dmytro Admin_test]

We are building an internal employee help center in Jira Service Management.

Our setup:

• Employees use Jira Service Management as Customers only. We do not want to assign paid JSM agent licenses to every employee.
• Employees have normal Atlassian accounts and can access the JSM Help Center.
• We have a private Microsoft SharePoint site that contains internal instructions.
• Employees already have permission to open these SharePoint documents directly with their Microsoft 365 accounts.
• SharePoint is connected to Atlassian through the Teamwork Graph / SharePoint connector.
• A Rovo Agent is published in the JSM Help Center.
• Microsoft SharePoint is selected as a knowledge source for the agent.

The Rovo Agent itself is available to the Customer, but for a newly created Customer it does not return information from SharePoint or show the SharePoint source/link.

For users with broader Jira/JSM access, SharePoint knowledge works correctly.

My questions are:

1. Can a JSM Customer without a paid JSM license use SharePoint knowledge through a Rovo Agent or Virtual Service Agent in the Help Center?
2. Does every Customer need to separately authenticate/connect their Microsoft 365 account to Atlassian/Rovo for SharePoint permissions to work?
3. If yes, how can a Customer do this when they do not have access to Rovo Search or the full Jira interface?
4. If this scenario is not supported, is the recommended architecture to synchronize SharePoint content into a Confluence Knowledge Base and let JSM Customers use the Confluence content instead?
5. Is there any native Atlassian-supported SharePoint → Confluence synchronization, or is Power Automate / REST API / a Marketplace app required?

Our target architecture is:

SharePoint as the source of truth → JSM Help Center AI assistant → free JSM Customers

We want employees to continue maintaining documentation only in SharePoint and avoid purchasing Jira/Confluence licenses for every employee.

I would appreciate confirmation of the officially supported architecture for this scenario.

[Gabriela - LeanZero]

Hi @Dmytro Admin_test, the half that works for you is expected. Unlicensed Atlassian accounts with the Customer role got Rovo agents in the help center when ROVO-119 shipped in March. Third-party knowledge did not come with it, and Atlassian states that part in words on the SharePoint knowledge doc: "Only Atlassian account holders with a valid Jira Service Management license can access articles from third-party sources in the help center." So no, not on a Customer seat, and that sentence covers the virtual service agent too.

Your second question is why. Connectors resolve permissions per person, and Atlassian's Rovo connectors guide is blunt about it: "Each end user is required to establish their own connection to the external app once connected by an admin." A Customer has no route to that step. JSDCLOUD-18831 reproduces it with a user who has an Atlassian account, the JSM Customer role and no access to any other roles or products, ending in "'Connect to Sharepoint' link is not visible in the filtered results". That configuration is the Atlassian-account side of the split @Rebekka Heilmann _viadee_ is asking about, and it matches your own line about employees holding normal Atlassian accounts. Atlassian closed it Not a bug, and the workaround is "provide access to any product (such as Jira or Confluence)". Which is the licence you're avoiding. The open request to push on is ROVO-1052, filed 14 July, still sitting on zero votes.

Worth ruling something out while you're in there. Linking SharePoint to the service space is a separate step from selecting it as a knowledge source on the agent, and the space one is what Atlassian documents: Space settings, Channels and self service, Knowledge base, Add knowledge, Microsoft SharePoint. It won't rescue the unlicensed case, because of the licence line above, but it takes misconfiguration off the table.

Confluence as the fallback does work, provided the content lands in an external knowledge base on the service space rather than as pages attached to the agent. "Support for unlicensed Confluence users" is listed as a capability external knowledge bases have and internal ones don't, and external articles are reachable "via customer-facing channels like the help center, portal, and virtual service agent".

For the sync itself I couldn't find anything native. Confluence has one-shot importers, Word, Google Doc and OneDrive, and none of them keep anything in step with the source afterwards. Microsoft's own Power Automate Confluence connector is four Get actions with no writes. So that leaves the REST API or a Marketplace app.

None of this is tested on my own tenant, it's the docs and the tracker.

[Rebekka Heilmann _viadee_]

Hi @Dmytro Admin_test 

Very interesting and avlid question!

Are these portal-only customer Accounts or are they Atlassian Accounts with JSM Customer App "license" that show up in your regular user directory? That may make a difference... 

[Вікторія Борс]

Hi Rebekka,

Most of them are portal-only customer accounts. They do not appear in our regular user directory in the admin panel; we can only see them in the Customers section of Jira Service Management.

We also tried inviting them as Atlassian accounts with the JSM Customer app role, without granting access to any other products, but the issue still persists.

[Dmytro Admin_test]

Hi @Rebekka Heilmann _viadee_ 
I did some additional testing and can now confirm the account types.

Test 1 - Atlassian account + JSM Customer

The user already had a normal Atlassian account and then joined our JSM Help Center. The same account appears under Business Tickets > Customers.

The user has the JSM Customer role and no paid Jira/JSM product access.

When testing access to our SharePoint knowledge through Rovo, the SharePoint content was not available.

Test 2 - Portal-only Customer

I also registered a completely new user directly through the JSM Help Center using an email address.

This user appears under Service Collection > portal-only customers and also under Business Tickets > Customers.

Again, SharePoint knowledge through Rovo was not available.

So I tested both:
- Atlassian account + unlicensed JSM Customer
- Portal-only Customer

In neither case could I access the connected SharePoint knowledge through Rovo.

Can you confirm whether SharePoint knowledge through Rovo requires licensed Jira/JSM product access?

If an unlicensed Atlassian account with the JSM Customer role is supported, where exactly can that user authorize or connect their Microsoft/SharePoint account if they do not have access to Rovo Search?

[Rebekka Heilmann _viadee_]

Hi @Dmytro Admin_test 

thanks for confirming. I'd lean on @Gabriela - LeanZero 's explanation.

[JSDCLOUD-18831] Customers cannot connect to sharepoint via JSM Customer Portal - Create and track feature requests for Atlassian products. already describes the problem outside of Rovo Agents.

[Gabriela - LeanZero]

Hi @Dmytro Admin_test , yes on the licence, and @Rebekka Heilmann _viadee_ 's account-type question turns out to split your two tests down the middle.

Test 1 is the case Atlassian shipped and then scoped. Jensen Fleming's rollout note on ROVO-119 lists what an unlicensed logged-in JSM user gets, and the knowledge line is "Receive agent responses based on sources they're already permitted to view from your JSM knowledge base". Ben Caldwell spelled out the consequence further down the same ticket: "For your unlicensed users Rovo will ONLY be able to provide answers based on JSM KBs. This is true even if the Rovo agent had other knowledge sources attached." SharePoint sits on your agent as a knowledge source. On an unlicensed seat it's skipped.

Test 2 fails a step earlier. Straight from the virtual service agent doc: "Rovo agents are currently only available in Jira Service Management portals for Atlassian Accounts." A portal-only account isn't one.

On where they'd authorize, the only end-user connect step Atlassian documents anywhere is in Confluence's search bar. "Go to Confluence and type in any search topic in the search bar. On the right side, select the app (for example, Google Drive), then select Connect." Which is also why that 18831 workaround names Confluence.

Still docs and the tracker. Nothing run on a tenant, and I don't know your plan tier, which matters for the virtual service agent half of your original question because that one wants Service Collection Premium or Enterprise on top.