Since its introduction in 2015, people have complained that Delve exposed documents to other users that they’d prefer not to share. In fact, the problem lies with poor permissions practice rather than Delve because Delve only ever shows information to a user which they are entitled to see. In many cases, problems arose when organizations migrated content from file servers to SharePoint Online without paying much attention to the permissions assigned to sites.
Delve is only interested in files stored in SharePoint Online and OneDrive for Business. The golden rule is that if the permissions on the SharePoint site or OneDrive account permit access to the content, Delve is happy to point people to those documents. On the other hand, if the permissions restrict access, Delve never shows them in its “Discover documents from people around you” section. The fact that I can see documents authored by James Ryan and Nancy Anderson (Figure 1) means that I have access to those files, even if I never knew that I did (until now).
SharePoint gurus quickly discovered that a managed property called HideFromDelve could be used to block Delve from displaying documents (including to their authors) while not stopping content being indexed. Microsoft documentation now covers how to use the HidefromDelve property.
Allowing users to hide individual documents from Delve is better than hiding complete sites from search results (another approach sometimes suggested). Hiding a site means that its content doesn’t show up in content searches and eDiscovery cases, which can become a big compliance problem. Because hiding data from searches is such a bad idea, Microsoft removed the ability for end users to block search access to their OneDrive for Business documents in 2019.
If you’d like to enable the HideFromDelve property for a site, you add it as a Yes/No column to make it available to views (Figure 2). Set the default to No unless you want new documents to become invisible to Delve.
After the column is added, users can set the flag by editing document properties (Figure 3).
After the flag is set, the next time the crawler processes the document it will note the new status and the document will be hidden from Delve.
Hiding a few documents from Delve isn’t good practice. A better solution is to educate users in how to set permissions correctly so that only the right people can access sensitive content. To some degree, the success of Microsoft 365 Groups and its membership model has made the task harder within Office 365. Everyone within a group/team has equal access to a document stored in the team site. It’s easy for people to forget who is in the membership of the group/team where they store a document, which can lead to inadvertent disclosure of sensitive information, including to guest members. Remember, a guest has the same rights over documents stored in the site as tenant members (here’s an article explaining how to report the files accessed by guest users).
Traditional SharePoint implementations (mostly in on-premises deployments) took a more structured approach to permissions, which were usually controlled carefully by site administrators. People looking after the sites used by groups and teams probably aren’t quite so careful.
Private channels can be a good solution for restricting confidential information. Each private channel has its own SharePoint site and access to that site is restricted to the membership of the private channel. Team members must be explicitly added to a private channel. You could therefore create private channels to host discussions and sharing of information which needs to be confined to a subset of team members, including guests. Search and Delve will respect the permissions set on the SharePoint site belonging to the private channel and only expose the documents stored there to the members of the private channel.
If you want to keep everything in a single site but only want certain people to be able to access certain documents, you can apply a sensitivity label with rights management (information protection or encryption) to those documents. Only the people assigned rights to access the content will be able to do so. Everyone else can see that a document exists in the library and view the document metadata (title, name, etc.), but they won’t be able to open the file. If you enable support for sensitivity labels in SharePoint Online, encrypted documents are indexed and discoverable by applications like Microsoft Search and Delve.
The fact that the metadata is not obscured must be considered by those responsible for confidential information. For instance, they might wish to name documents using code names rather than more understandable terms to disguise their content. For instance, use “Document 001” as a name instead of “Potential Merger with Acme Corporation.”
The serious point at the end of this story is that organizations should think about information governance for their tenant. Some will want to encourage free access to information and not worry too much about permissions. Others will be much more concerned. Each needs to find its own balance, preferably without relying too much on hiding documents from Delve.