Office 365 has an impressive search capability, built in part on Office Delve. Office Delve is a service not only for search across Office 365, but for connecting to other users and organizing documents in a way that is meaningful for you.
Like a lot of powerful tools (the wheel, flathead screwdrivers, and nuclear reactors), Delve is really effective at what it does, and it does a lot. However, there are some caveats to be aware of, caveats that are easier explained by explaining Delve, rather than highlighted in bullet-point format.
Let’s start with Microsoft’s definition of what Delve is: a way to manage your Office 365 profile, and to discover and organize information from across Office 365.
Delve works by indexing, silently and in the background, all content available in Office 365. As an end user, you will never see Delve doing this. Delve is actually built on top of Microsoft Graph, which is a deeper “gateway to data and intelligence”. Things like identifying trending data and network clusters of people or files, that’s what Graph does. Delve just leverages Graph to surface content that is relevant to a specific user in Office 365.
Generally, this means that as a user, my searches will be more relevant to me. If I search for “memo” I’ll see memos from my team before I see memos from Accounting in Japan. If I search for “Joe Smith” I’ll see the contact card for Joe in my department before Joe in California, and so on.
On the other hand, this means the end of “security by obscurity”. Delve respects security trim, so I won’t see content that I don’t have permissions to see. However, for business units that have grown up without a sophisticated enterprise search mechanism like Delve, sloppy permissions carried into Office 365 will mean that anyone who accidentally uses the right terms in search will stumble across “sales_document.xlsx”, which contains salaries and bonus payouts for all the sales teams.
That’s how sensitive information gets posted on social media: Powerful Search + Weak Permissions = Open Access. While Microsoft assures you that documents are safe in Office Delve, it’s useful to understand how it works, along with the following caveats.
Caveat #1: Farewell, security by obscurity.
By relying on indexed search, Delve is fast. It’s not literally searching every document everywhere when you enter a search; it’s looking at an index. But, that means that content must be accessible.
First of all, that means it needs to be in Office 365. Leveraging Box or DropBox for archives or cloud storage? At a minimum you’ll need a connector to allow SharePoint Online to see those sources as SharePoint sites. You’re better off migrating to SharePoint Online and OneDrive.
Microsoft even tells you this. “. . .you can start storing your documents in OneDrive for Business and share them with your colleagues.” Why yes, Microsoft, we can do that. Doesn’t mean we will, or should. Few people want to do the wrong thing, but everyone wants to do the convenient thing. Sharing to everyone, or to the first group or name that looks correct, is convenient.
Second, it means that documents which are not indexed will not show up in search. While this may sound like a way to address the “security by obscurity” caveat described above, it does so in a way that denies functionality to users. More on this in the next caveat, which is . . .
Caveat #2: Must be present to win – or be found.
There are two parts to this caveat, and they basically come down to: someone wants the document to be found, or someone doesn’t want the document to be found.
If you want Delve to find a document, the document has to be present. This may sound silly if you’ve planted both figurative feet in the Office 365 space, but if you’re still in an hybrid or bifurcated collaboration environment, users may not understand that Delve (or “search” as they probably refer to it generically) won’t find things that are not in Office 365 – files on file shares, local to their PC, or in some other cloud storage, etc.
If you don’t want a document found, there’s a pretty simple workaround that any Site Collection Administrator can put together: create a custom column, yes/no, of the type “HideFromDelve”. You can read about it here, here (option #2), and here.
In an enterprise, there may be some disagreement about who gets to make the decision as to whether content should be discoverable via search. The right approach will depend on how that decision gets made, and may require some third-party solutions or development to provide the required finesse.
Caveat #3: Indexing is Not Instantaneous
Indexing is not an instantaneous process. Ask anyone who’s managed on-premise search crawl; be aware that it’s not magically faster in the cloud. This means that newly-created documents won’t show up, and changes to documents, if the changes are the search criteria, won’t show up either. It can take a day or so for things to show up in search.
This might not seem like a big deal if you’re a regular person working in small groups, accustomed to people sharing links and putting content in the right place. However, if you’re responsible for finding content across a broad spectrum of groups, search is invaluable.
Indexing speed also affects other processes. Relying on native retention and sensitivity labels? That’s a function of search as well. Without using more expensive Azure service licenses or third-party tools, your retention and sensitivity labels could take a day or longer to be applied.
Summary
Office 365 Search (Delve) is a powerful tool, and for most end users, it’s seamless, transparent, and effective. However, Office 365 administrators should understand how it works, in order to establish the configurations and processes that support business requirements – whether that’s making it easier to find content via search, or to prevent some content from being found.