When admins connect SharePoint to Rovo, the goal is to make knowledge more accessible. Teams can search across shared content, get answers in chat, and find what they need without hunting through folder structures.
The question most IT and security teams ask before enabling this: how do I keep sensitive files out of it?
Good news. Rovo now supports Microsoft Information Protection (MIP) sensitivity label blocking for SharePoint. You configure a blocklist of label IDs once, and Rovo respects it across your entire tenant, regardless of which site a file lives in or which group owns it.
The problem with other controls
Rovo has offered site-level and group-level controls for a while. They work well for specific use cases, but they have a structural limitation that sensitivity labels do not.
Site blocklists require you to enumerate every site that contains sensitive content. Add a new project site with confidential documents? You need to remember to add it to the list. A file gets moved from a restricted site to an unblocked one? It's now in Rovo's index.
User group scoping (available for OneDrive) limits which users' data gets ingested. Useful for reducing scope, but it doesn't address the content itself. A confidential document shared with a broad group still gets ingested if those users are in scope.
Here is the difference: with sensitivity labels, the rule is attached to the document, not to where the document happens to live. A file classified as "Confidential" is blocked whether it is in a legal team's site, a shared collaboration space, or a personal OneDrive folder.
What's shipping
Rovo's SharePoint connector now reads MIP sensitivity labels during ingestion. Admins add label GUIDs to a blocklist in the connector settings. Any file (or entire site) carrying a blocked label is skipped. None of its content, metadata, or embeddings reach Rovo's index.
This works at two levels:
-
Document-level: individual files with a blocked label are skipped regardless of which site they are in
-
Site-level: if a site itself is labeled (e.g., marked Confidential at the site level), Rovo skips the entire site in one step
For content that was already indexed before you configured the policy: it stops appearing in Rovo search immediately, and is purged from the index on the next full scan.
Why it's different
One policy, tenant-wide coverage
You configure a label GUID once. From that point, every file in your tenant with that label is blocked (including files already indexed), regardless of where it lives or how your SharePoint is organized. No list of sites to maintain, no group memberships to audit.
Labels follow the document
When a file moves between SharePoint sites, its sensitivity label moves with it. The Rovo blocklist doesn't need to change. If your organization regularly moves files between sites or libraries, the protection follows automatically.
Complements your existing controls
Sensitivity labels don't replace site blocklists or group scoping; they layer on top. You might block high-sensitivity tiers (Highly Confidential, Restricted) via the label policy, exclude specific project sites via the blocklist, and scope OneDrive to a subset of users via group controls. Each mechanism covers a different kind of risk.
Rovo stays valuable
The point isn't to block everything. It's to block what genuinely shouldn't be in scope, and let everything else flow through.
A well-configured label policy means your legal and finance teams can work knowing their most sensitive documents won't surface in a chat response for the wrong person. The rest of your organization still gets full access to shared knowledge through Rovo's search and chat.
Before and after
Without a sensitivity label policy:
|
File
|
Label
|
In Rovo?
|
|---|
|
Q3 financial projections.xlsx
|
Confidential
|
Yes
|
|
HR investigation notes.docx
|
Highly Confidential
|
Yes
|
|
Engineering onboarding guide.pdf
|
General
|
Yes
|
|
Product roadmap.pptx
|
Internal
|
Yes
|
With Confidential and Highly Confidential blocked:
|
File
|
Label
|
In Rovo?
|
|---|
|
Q3 financial projections.xlsx
|
Confidential
|
No (blocked)
|
|
HR investigation notes.docx
|
Highly Confidential
|
No (blocked)
|
|
Engineering onboarding guide.pdf
|
General
|
Yes
|
|
Product roadmap.pptx
|
Internal
|
Yes
|
Getting started
Configuration takes three steps:
-
Get your label IDs from Microsoft Graph Explorer, not directly from the Microsoft Purview portal. Purview can show a different “name” GUID; Rovo needs the Microsoft Graph sensitivity label id.
In Microsoft Graph Explorer, sign in with an admin account that has SensitivityLabels.Read.All, then run one of these queries:
<a href="https://graph.microsoft.com/v1.0/security/dataSecurityAndGovernance/sensitivityLabels?%24select=id,name,sublabels" rel="noopener nofollow noreferrer" target="_blank">https://graph.microsoft.com/v1.0/security/dataSecurityAndGovernance/sensitivityLabels?$select=id,name,sublabels</a>
Use the id field in the response. If you need the beta endpoint, you can also use:
<a href="https://graph.microsoft.com/beta/dataClassification/sensitivityLabels?%24select=id,displayName,sublabels" rel="noopener nofollow noreferrer" target="_blank">https://graph.microsoft.com/beta/dataClassification/sensitivityLabels?$select=id,displayName,sublabels</a>
-
Open the SharePoint connector settings in Rovo Admin Hub (Admin Hub > Apps > Connectors > Microsoft SharePoint and OneDrive > Choose content to include > Limit by label).
-
Paste the GUIDs into the blocklist input, one per line, and save.
Changes take effect on the next full scan (monthly cadence; allow up to two weeks for large tenants). See the admin guide for the full walkthrough with screenshots.
What's next
Sensitivity label blocking is live for the Microsoft SharePoint and OneDrive connector. We are evaluating bringing this control to additional connectors.
If you have feedback or questions, post in the Atlassian Community or reach out through your customer success contact.
