Last year I published a blog all about Delve and the Office Graph for the European SharePoint Conference. If you’re not exactly sure what Delve or the Office Graph are, reading that post would be a good and quick primer for this article. In that post, I included one paragraph about how to exclude content from Delve. In this blog we’ll explore that topic more deeply.

As Delve has gained popularity I’m having more and more conversations with customers, as well as seeing conversations in Yammer and other online venues, about security, privacy and compliance with Delve. Customers are asking questions such as:

• How can I prevent sensitive content from showing up in the wrong person’s Delve board?
• Can I role Delve out to a limited set of users for a pilot?
• Can I exclude certain people from using it?
• Can I exclude a certain types of content?
• and other similar questions…

You’ll notice that these questions come in two forms:

1. How do I control the content surfaced in Delve?
2. How do I control which people can use Delve?

These are good questions which we’ll venture to address in this post.

Delve Honors Permissions

Microsoft has done a good job of sending the message that no one will ever see content that they do not already have permissions to see. That is, Delve honors the permissions that have been set in Office 365 for the content in question.  Just like SharePoint sites, documents, libraries, search results, etc., Delve employs “security trimming” so that any content that the current user does not have permissions to view is “trimmed” from their view. Microsoft even include that message right in the user interface of Delve, which is a very smart idea.

Clicking on that link highlighted in the screenshot above will take you to a page titled “Are my documents safe in Office Delve?”.  It’s a good and simple information page that answers questions new Delve users may have about the safety of their docs. It primarily reinforces that Delve honors security, and walks through some of the visual indicators that will clue users into who can view the document.

Are Permissions Good Enough?

Knowing that Delve honors native Office 365 permissions may put many of you at ease, but personally I’ve been around SharePoint long enough to know that many (most, perhaps all!) customers have some issues with permissions. SharePoint and OneDrive for Business offer a lot of flexibility around how site and document owners can adjust permissions. And organizations are always trying to strike that balance between ease-of-use, flexibility vs. security/risk. But the reality is that permissions are not always set properly – meaning some users will have access to documents that they shouldn’t.

Security through Obscurity

When I was a full-time Enterprise Search consultant, this problem would come up all the time. For example, a customer has many file shares. Deeply nested inside the hierarchy of those file share folders, there may be a folder or document that a user has access to, but shouldn’t. The risk here is pretty low, because even though permissions have not been applied properly, it is unlikely that the user will ever come across this file because they would have to drill through dozens of folders and somehow stumble onto the content in question. This is called “security through obscurity” (it’s secure because users can’t easily see it). But, if we crawl the file shares and the content may now show up in search results, all of the sudden their permissions flaws may start to show and users may start seeing documents that they shouldn’t. This is not a flaw of Search, it is a lack of content stewardship. But the risk is there nonetheless.

Now we have technologies like Delve, where a user doesn’t even have to proactively search to find content, but it is surfaced automatically. The risk of finding improperly secured content has gone up a bit. This is not a flaw of Delve, but a lack of content stewardship. I highly recommend that customers do not take the position to simply disable Delve, Search and other discovery technologies, but rather that they address permissions issues on an ongoing basis. Some tips on this point:

• Take content stewardship seriously! Technology is moving in the direction of automatic discovery. If you don’t want content accidentally discovered, make sure you’re securing it properly!
• Design and adhere to an information architecture that supports your permissions requirements.
• Design and enforce governance policies around how content can and should be shared and where specific types of content should reside. Remember, if you can’t enforce it, you don’t have a governance policy.

Beyond Permissions

I hope I’ve convinced you that 1) Delve will respect your well applied permissions, and 2) you better have well applied permissions! But what about content where the permissions are fine as they are, but you simply don’t want it to show up in Delve? Microsoft has provided a mechanism for this called HideFromDelve. You can find details about how to configure this in the article titled “Manage the Search Schema in SharePoint Online”, but essentially it works like this:

For documents that you want to exclude from Delve, the steps are:

1. Add a yes/no site column called “HideFromDelve” to the library where the document is stored.
2. Edit the properties of the document you want to hide and click the new HideFromDelve checkbox.
3. The next time the content is crawled, the document will no longer show up in Delve.

Behind the scenes, what this does is creates a Search Managed Property called HideFromDelve. When Delve performs its query to retrieve the relevant documents for the current user, the query explicitly excludes content where “HideFromDelve = True”.

It’s a simple solution and works quite well, especially for the occasional document. Here are some caveats though:

1. If you wanted to implement this enterprise-wide, it would be difficult to ensure that this field is available on every existing and future document library, educate users about it and trust that they know whether this should be excluded or not.
2. The user has control over this field. So if you have a custom or 3rd party tool that sets this field automatically, based on compliance rules for example, the user could simply change it back.
3. This is “Hide From Delve”, not “Hide From Office Graph” (if you’re not sure of the difference, again, check out last year’s post on this topic). What that means is that it will be excluded from Delve boards, but not necessarily from anything else that’s leveraging the Office Graph, such as custom or 3rd party solutions.
4. It obviously only works for items stored in document libraries.

People-Centric Control

So far, we’ve only talked about controlling Delve at a content level. But equally important is controlling at a user or group level.

Let’s start with what Delve provides out-of-the-box for excluding people from using Delve.

1. The Office 365 Administrator can enable or disable Delve and the Office Graph off for the entire tenant. This is done by navigating to the Settings area within the O365 SharePoint Admin center.

2. Individual users can individually opt out of sharing their documents with Delve and the Office Graph right from the “cog” within Delve.

These are pretty straight-forward options. But here are some of the things I’ve heard from customers.

• I want to role Delve out as a pilot. How do I do that?
• I have a group of users working on highly sensitive content. I want them excluded from Delve.
• I want to exclude my HR department.
• I want exclude C-Levels from Delve.

To accomplish these, and especially to enforce them would require customization or 3rd party tools.

Key Takeaways

• Delve absolutely honors all permissions set in SharePoint and OneDrive for Business. No one will ever see anything they don’t already have access to.
• As with any discovery tool, Delve could potentially expose improperly configured permissions.
• That should be a motivator to address permissions issues – not to disable Delve, search and other discovery tools which provide a lot of value.
• Office 365 natively provides some simple ways of excluding people and content from Delve, if necessary.
• For anything automated or based on business intelligence, look to 3rd party tools or customization.

About the Author: 

Paul Olenick is Director of Product Strategy for AvePoint with more than 13 years of IT experience in areas such as development, administration, architecture, and solution design in Microsoft Office SharePoint and Office 365. He is a recognized Microsoft expert, having been named a Microsoft SharePoint Most Valuable Professional (MVP) in 2012, 2013, 2014 and 2015, a Microsoft Virtual Technical Solutions Professional (V-TSP), and a Microsoft Certified Technology Specialist (MCT). Paul has been dedicated exclusively to SharePoint since 2006 and has a special interest and deep expertise in search and discovery. Paul has helped clients worldwide solve business problems by leveraging SharePoint and Enterprise Search, and shares his experiences with the greater SharePoint community by contributing to books, blogging at olenicksharepoint.com, and speaking at industry events. Paul is a seasoned speaker and presenter, having led sessions at two SharePoint Conferences (2012 & 2014) and many other international conferences and local events.

Follow Paul on Twitter: @olenickSP