15 Reasons Not to Use Folders in SharePoint (and 3 reasons why you could)

I hate folders as a means of organising content. It’s a deeply broken approach and carrying it over to SharePoint is one of my pet hates. I have even written a song about it. So I pulled this together from my involvement in various conversations and involvement in a discussion arising from an article written by Gregory Zelfond. http://sharepointmaven.com/12-reasons-folders-sharepoint-bad-idea/

  1. No right place – this is the biggest issue and most easily understood; folders force you to put a document or file in a single location, even if it might legitimately be associated with several places. A project report could be put in a folder with all the other documents for that project, or in a folder for reports, or in a folder for documents that are archived; in reality it should be in all three but that creates duplicates. SharePoint metadata would let you tag the document as being a Report, associate it with a Project, set its status to Archived and more. Different views would let you see (or hide) all Archive documents, all project reports, all documents that are not in draft that have be modified by me in the last 7 days and include the Technology tag, etcetera, etcetera. And you can switch between views with a single click.
  2. Usability – Unless you have a rigorous and actively managed file plan (and, let’s face it, no one actually does this well) then the folder structure is only known to the person/team who created it. Everyone else has to inefficiently browse the contents hidden in the folders in the hope of finding the document or file.
  3. URL length limitation – SharePoint builds the URL using all folder and sub-folder. However the URL length is limited to around 255 characters; beyond that you get an error. Deep folder structures simply break in SharePoint.
  4. Unfixed URL – Moving a file from one folder to another changes the file URL, so any fixed links to it will break.
  5. Security – You can use folders to define security for groups of files in SharePoint, however ongoing management of this is as big an administrative nightmare as it is on file servers.
  6. User experience – The user experience (UX, navigation, finding the documents) is marginally worse than it is on file servers – it’s slow, content is hidden until you open the folder. Moving content within folders is terrible within the browser, navigating between folders is horrible too. (though you can open the library in Windows Explorer).
  7. File duplication – Folders actively cause file duplication, partly because there is no one, right place for a given document or file (in fact you often have to put a file in multiple paces because folders are so inflexible), partly because you can’t see that the file already exists elsewhere. If you are striving for a ‘single version of the truth’ then creating duplicates immediately undermines this principle.
  8. A single view – One of SharePoint’s many great features is the ability to have multiple views of content, with the flexibility for users to filter and modify the view on an ad hoc, temporary basis. But not with folders, in a folder view you get just one view of your content and it is pretty poor, for the reasons above and below. Using metadata, you can create unlimited number of views by whatever properties you have setup (i.e. organize documents by date, by customer, by project, etc.) .
  9. Can’t Sort & Filter – Burying files in folders means you can only benefit from the sorting and filtering capabilities of document libraries and metadata navigation within the folder you are in.
  10. Inflexible – It’s hard to change the folder structure (though again you can use Windows Explorer), while changing metadata is easy and can be done as bulk actions.
  11. Lost documents – It is so very easy to misplace documents by putting it in the wrong folder and not knowing where it is. So then you create a duplicate copy, and the mess begins.
  12. Navigation – When you are in a particular sub-folder, there is no easy way to tell which folder you are in and no easy way to navigate to the parent folder, a sibling folder etc. since there is no breadcrumb trail or tree view by default.;
  13. Cost – If all you are doing is recreating the same mess of nested folders you had on file share within SharePoint all you have done is increase the cost (SharePoint infrastructure is more expensive than a file server) and you have cunningly avoided almost all the benefits of SharePoint.
  14. Visibility – the only way to know how active a folder is/how many documents it contains is to open it. It could be empty; it could have ten thousand documents; you just don’t know. A grouped SharePoint view in SharePoint using metadata shows many docs are in each group (and lets you carry out counts and other basic arithmetic on column values, such as Average file size). If there are no items in a group then the group doesn’t clutter up the screen.

    The power of SharePoint views - who needs folders when you can have groups, filters, metadata navigation and more?

    The power of SharePoint views – who needs folders when you can have groups, filters, metadata navigation and more?

  15. Data Integrity – There is little control over the naming of folders, so you can have spelling errors, non-standard conventions, unhelpful abbreviations etc. Metadata driven views can be driven by lists and taxonomies to avoid this.


The big problem is that folders are traditionally used to categorise content, whereas they were originally designed to group content. Just because we have learned to use folders inappropriately doesn’t mean we should continue to do so. However folders have some legitimacy for their original purpose. If you genuinely need to group files together then you can use a folder in SharePoint; this is usually because you need to perform a group action on them, such as delete them all. Similarly folders may be used (despite point 5 above) to assign grouped security to the content – simply moving a file into the folder gives it some security; as long as the security rules are very simple to apply and understand. In both cases you still should avoid folders – use a Document Set instead, since they are much more powerful, intelligent and intuitive. Even then we strongly advocate having only a single level of folders and never, ever more than two,

The only other reason for retaining is that you can’t get users to adopt the new, better way of doing things. At this point you have to use your judgement – generally staff work for the company and the company can dictate ways of working; there are rules for not operating machines without guards, even though they can be somewhat inconvenient for operators (until it saves one losing an arm); the digital health of your knowledge is as important. However if a team or individual chooses to stick with folders for their own content then that may be OK; as long as it doesn’t disadvantage other staff and that they aren’t wasting company resources (working time, support desk resources, computing time) in the process. A suitable policy for use of your intranet can address this – shared content, core business processes, managed information should not allow use of folders in libraries; personal and team working areas may use folders, but should avoid deeply nested folders, should also use flat views (where the folder structure is hidden) and must be actively managed by the team to avoid duplicates and misfiling.


Filed under Best Practice, Content management, Improvement, Intranet, SharePoint, Windows

Folders are dreadful. Teams is great. Teams uses folders. Discuss…

A while ago I wrote a (carefully considered) rant about the evil that is the Folder. I dislike folders so much that I wrote a song about them (well, part of a song, but in this I am definitely allowed artistic license.) Yet I am clearly on record as a bit of a Microsoft Teams convert, and Teams uses folders, not grown up metadata. See if you can spot what’s wrong with this picture…

“Microsoft Teams… the Saviour of the Universe (ah aah)”

If you have had any interaction with Microsoft of late, you would be easily forgiven for thinking that. While I am an ardent lover of the power, sophistication and flexibility of SharePoint, I would concede that it is a complex platform and it’s very easy to develop ‘bad’ solutions on it that do not get great engagement from staff (unless done really well, which is what we do in Cloud2, but that’s a different story). So complex that MS were close to abandoning it as even they didn’t really understand what they had created. Then Jeff Teper came along and painted a new vision and the SharePoint garden is flowering nicely; however, that doesn’t get around the issue that it is a serious application that needs developing into a solution before it can be used. I even wrote a blog on how SharePoint is like Lego, but that was long ago in a galaxy far away. Meanwhile some folk at MS were playing and invented what became MS Teams, which provides a really simple experience for users, combining team chat (like Skype for Business chat, but with Slack like persistence and for persistent groups of people), combined with a Files tab and some other useful stuff. But you knew all that, didn’t you? You probably also knew that the Files tab is actually a SharePoint library and the act of creating a Teams Area spins up a full, linked SharePoint site collection. Teams Areas can have additional Channels, usually orientated around a work stream, activity or sub-team and these also have their own Files tab. However, go exploring these in SharePoint and it’s quickly apparent that each channel’s files are simply in a folder in the SharePoint library, with the same name as the channel. You can add metadata, views, content types etc in the library as normal; however these resolutely fail to appear in Teams (unless you manually add additional tabs that point at the libraries). Instead, the only way to organise your files within a Channel is to create folders and these become sub-folders in the channel folder in the library. Following so far?

In Teams it’s all pretty simple; end users wedded to the noxious horror of folder structures can carry on regardless and no one has to train, encourage/threaten them to experience modern thinking on knowledge management (it’s only been 20+ years after all). Perhaps I’m being unkind; Teams is rather nicely pitched at the ordinary ‘Joe User’ who just needs to have a simple experience and do stuff quickly; there is nothing initially wrong with that. Except that these systems always end up growing to the point of dysfunction as more and more content is added; it’s a sort of Digital Peter Principle. Despite years of best practice, evangelism and dire warning about the issues of folders (and everyone’s’ personal experience of how badly broken all shared drives on file servers are), MS have created a brand-new monster. How we laughed.


One of the cool things about Teams, is that it is fairly extensible; you can add new tabs, link stuff together, use content from other applications via connectors; even fire up workflows and embed applications in tabs. You can also bounce people up into ShrePoint for all the sophisticated stuff about 20% of use cases will ultimately need. But if you allow your information architecture to be screwed up then it’s a nasty, soulless job to fix it for that 20%. What you really need is some way to bridge the gulf between a fast-adoption, simple-to-understand Teams experience and an enhanced, life cycle-managed, compliant SharePoint one. Your users (mistakenly) want folders, your organisation needs metadata.

This issue has vexed me for some time, until a timely conversation with the redoubtable Jon Burton about this exact issue (how he laughed). Being a kind soul, I like to not only offer things to fear, or be intrigued by, but also provide solutions to real-world issues. So, I present to you… ‘Content categorisation based on Folder names’

This is his not actually a new concept. In the Folders blog, I talk about how most folder names are really just a crude and somewhat ineffective way of categorising things. In fact one of our earliest clients, Paul Kendrick, bemoaned that Microsoft had no function that let users drop documents into folders and turned that into metadata. We have even used this concept in Hadron Migrate, our file system to SharePoint rapid migration tool. The trick, in this case, is to write a Flow. It works like this

It is triggered overnight or whenever new content is added to the Teams Area library.

It uses the Is Folder function to identify the Top Level folder name in the folder tree (which will be the Teams Area Channel) and use the Update function to write this into a Channel column in the library for each document.

It uses the same Is Folder name of the immediate parent folder of the file and Update that into a Category and/or Keyword column.

Before this we would deploy content types to the libraries that contain the required columns. We would also create a set of metadata driven views that are set to ignore folders  and show content Grouped by Channel. Filtered as needed

Until such time as Microsoft do provide full metadata and view support in the Files tab (it’s coming, they claim) then we would add the library into a further tab, to allow a rich navigation of content as required.

It’s pretty neat; combining the simple and sophisticated worlds. You could even use it in SharePoint without Teams being involved. How about having a Drop Off folder, that users can create their own sub folders in and the content is then tagged, moved, or otherwise processed. If you want to get really sophisticated, then we would use some cognitive services stuff to extract keywords from the document content and use that to further tag the documents. But that a different blog entirely (but like the one on autotagging images)





Filed under Collaboration, Content management, Office 365

Is Check in/Out still relevant in 2018?

The thing with blogs is that one tends to write about subjects that one is interested in, or even passionate about. Often this results in excessive evangelism, sometimes it can turn into a rant. It would be a stretch to classify this as the former (but if you want an unequivocal rant read what I think about Folders)…

SharePoint is a marvellous piece of technology, offering a massive breadth of tools and some especially neat ways of managing documents and other content. It also includes some legacy features which have become largely superfluous, but which some organisations cling onto, not realising how best practice has moved on. This blog considers one of these, Check In/Check Out, why it should almost never be used and the few occasions when it still has a role to play.


As with most things Microsoft, the level of integration between different elements of the Microsoft stack is outstanding, and it often seems that the entire suite of Microsoft products advances in strict lock time, each taking advantage of the new features of other parts. There have been notable exceptions over the years, or course, but that’s the subject of a future blog.

Frequently, the collective improvements border on being a revelation, if not a revolution; they offer the possibility of radically changing business processes and supplanting previous good practice with better practice still.

One such ‘aha’ moment was the introduction of multi-author editing into Microsoft Office, and especially Microsoft Word, using the capabilities of SharePoint and OneDrive to handle the streaming of document updates in almost real-time. This is such a brilliant thing that it’s hard to imagine a world without it. However, prior to its introduction 10 years ago, we were burdened with a world where we either emailed documents amongst people and hoped to reassemble them, painstakingly and not without error, from the arbitrarily edited and often conflicting versions; or else we did the smart thing and saved them into an early version of SharePoint so that we could all work on a single copy of the document. Best practice, back then, was to check a document out while you’re editing, this locked the document and ensured that we didn’t experience the pain of conflicting edits where someone else saved their changes over yours, eradicating hours of important work. However, best practice or not, ‘Check Out’ and ‘Check In’ are, much like folders, an invention of Beelzebub, historically necessary but deeply evil. They serve their purpose to protect the document from overlapping changes, but they do nothing to protect hopeful document editors from colleagues who check a document out, forget about it and go on holiday, usually for two weeks (often more in Europe).

Time and again, check out has been demonstrated to erode efficient editing processes and to create a real governance and compliance risk. Checked out documents cannot be further updated by others; when such updates are needed in a hurry (usually not long before an audit is due), the only recourse is to create a copy of the document and work on that. This practice deeply undermines the single-source of truth philosophy that should underpin good content management. Of course, you could call a SharePoint administrator and ask them to cancel the check out; but that’s slow, burdensome on the admin and inevitably means that whatever updates that the check-out miscreant had (lovingly?) crafted are lost.

Thankfully, we are living in a new decade, where multi-author editing is a standard feature of the Microsoft technology stack and operates so slickly and transparently that it’s a doddle to use and it’s comparatively hard to screw up. When using Word and its kin, you can see who else is working on a document, see which bits they are editing and see their changes appear almost as they type in most cases. You can even contact the other author directly from the document to clarify wording etc. or flag a point to them using an @mention in a comment. Documents are never locked, version control and version history ensure that previous versions remain accessible and roll back is simple if required, tracking of edits ensures enhanced visibility and review. It’s bloody impressive and major step forward in productivity and compliance, doubly so if you have a distributed team or ‘agile’ timelines.

So why, oh why, do some organisations still insist on using Check In /Check Out? Here are some thoughts, excluding the obvious “They are blithering idiots” option which I wouldn’t dream of putting in writing anywhere:

  1. A lack of active learning about the technology across the organisation has resulted in no one realising what the new tools can do. This is a shame, especially as you are paying for all those new features on an annual basis if you have a cloud-service subscription. Given that the technology costs can run to £manyhundredsofK for larger organisations it seems that a bit of investment in getting ongoing and increasing value from the tools would be wise.
  2. Inflexible culture might to be to blame; I do come across “it was good enough for my grandfather” organisations, where they hang on to the old ways because they were fine in the old days. However, I don’t see so many of these any more, since most of them have gone out of business. It’s a rapidly changing, hugely competitive world and organisations need to flex with it. Including public sector ones, who owe the tax payers a duty to spend money wisely.
  3. Inflexible processes, where it’s so hard to change something that has been written into a policy or procedure that only critical changes are pushed through. Actually, this is often another symptom of the culture and has identical outcomes.
  4. Someone in IT or the outsourced services department decides that Check In is the right thing to do, that it is somehow safer or better. I can think of a handful of scenarios where this is actually true. But the other 99% of the time it’s nonsense and professionals or consultants who are paid to know better telling organisations that they should base their policies on it should be a criminal offense (I would make it a capital offense, but I’m a liberal kind of guy and reserve that for only the most heinous of crimes, such as Folder abuse); or at least ground for renegotiating contracts.


The bottom line is that organisations should have Check In/Out turned off as the default position. Version Control is generally already on (almost certainly true already if you are using SharePoint Online) and every version of Microsoft Office from 2010 onwards supports multi-author editing which ensures that changes are seamlessly managed.


So, go and check all your libraries now and turn that option off. It’s in Library Settings, Version Settings. Think about your version control settings while you are there.

Version Control settings

If you think you might need to use Check Out then have a conversation with someone about the specific use case and see if you can really justify it. If you are stuck for someone to ask, drop me a line – but don’t expect an easy ride.


Leave a comment

Filed under Best Practice, Content management, Office 365, SharePoint

Microsoft Teams Best Practice

It would be fair to say that I have become something of a Teams convert. Maybe even an evangelist. With that in mind, here is a round up of what I consider to be some good and best practice for use with Microsoft Teams. Teams is so new that new features are emerging all the time and use cases and associated practice are also emerging, so any of this is subject to change.

  1. Turn it on! You can do this in the O365 Portal and you can assign licences to all users or a selection. PowerShell scripts can help if you need to be selective.
  2. Call each team in Teams the ‘Teams Area’ or ‘Area’ for short. The language gets really messy otherwise.
  3. Have a naming convention for each Teams Area. At the minimum this should include the owning department or function and the purpose of the Team, e.g. Sales – Tendersteams request flow
    1. Have a clear naming convention to differentiate between Live and Test Team sites. You could add -Test on the end or add an asterisk or other character to indicate temporary or test Areas
    2. It’s also useful to add the date it was created, so dormant Areas can be removed.
    3. Remember that each Area also gets an email address. Make sure these group addresses don’t conflict with existing email groups.
    4. If you need extra control, only let new Areas be created via a Flow, with approval. See the screen shot for what you might want to capture; you then need to use a Custom Connector (as there isn’t a direct option in the Teams connector yet), but there is a useful option already on Github for this
  4. If you want a SharePoint Site, but also use Teams then make sure that you create the Teams area first; it will create a group and a Modern SharePoint site for you.
    1. You can do it the other way and link a new Area to an existing site, but only of that site has a Group already.
  5. Ensure that someone reviews the range of Teams from time to time and ensures that they meet the naming convention, as well as removing dormant or duplicate Areas.
    1. Create a Flow to notify an Admin whenever a new Area s created
    2. Check that every Area has more than one owner, just in case one of those knocked over by a bus scenarios happens; or that the Area owner is on leave.
  6. Use Channels to separate out different workstreams, topic areas etc.
  7. Remember that there is currently security at the Areas level but not at the Channel level. Anyone in a specific team can see all the content of all the channels in that Team Area. Don’t share sensitive Areas; consider having a second Area for each external person or group you share with. Use the Move or Copy function to shift files etc between the two.
  8. Get to grips with tabs
    1. Remove the Wiki tab – it’s hopeless. Add a link to your own OneNote pages, tabs etc instead
    2. Add pages, applications and SharePoint libraries and Lists as tabs in channels, to create a joined up working environment.
    3. If you use Dynamics, read this: https://community.dynamics.com/365/sales/b/d365forteams/archive/2018/12/07/best-practice-using-microsoft-teams-with-dynamics-365
  9. Add metadata to the libraries (via the SharePoint site), even though it doesn’t currently appear in the Files tab in Teams. It will at some point and you’ll be glad you have the extra control, filtering etc.
  10. Learn about Guest access
    1. Guests users have a bunch of restrictions – make sure people (and your help desk) know about them: https://docs.microsoft.com/en-us/MicrosoftTeams/guest-access
    2. Remember that you can only have 5 guest users per real user – actively remove dormant guests from time to time
    3. An Admin can invite up to 2000 guests at a time, via a CSV file and using Active Directory B2B (https://docs.microsoft.com/en-gb/azure/active-directory/b2b/what-is-b2b)
    4. You need to turn on and manage Guest access:
      1. Sign in at Office 365 global admin portal; in the navigation menu, choose Settings and select Services & add-ins; Select Microsoft Teams;
      2. In Select the user/license type you want to configure, select Guest; Click or tap the toggle next to Turn Microsoft Teams on or off for all users of this type to On; Choose Save.
    5. Global admins can choose, who will be able to invite guest users to an organisation:
      1. Directory admins and users in the guest inviter role;
      2. AAD members;
      3. Guests.
  11. Don’t forget that every Area has an associated SharePoint site.
    1. Make sure users know how to easily access those; ensure that these sites are discoverable from within your intranet (i.e. add them to your navigation), and encourage Area owners to update and format their sites.
    2. It’s a good idea to create a SharePoint Hub site and associate all the Teams Areas sites to that hub.
  12. Establish some Chat etiquette. Area owners should help police this and remind users of the etiquette
    1. Use @name in a team chat to ensure someone gets a notification
    2. Always use Reply to add commentary to a thread
    3. Keep conversations focused in the right channel and Area.
    4. Don’t say thanks etc to every chat; you can hover over the chat and click the Like icon if you want to acknowledge someone.
  13. Consider setting up some policies for how Teams should be used
    1. Review the audit log for events etc. from time to time (https://docs.microsoft.com/en-us/MicrosoftTeams/audit-log-events); you need to turn it on though. It can tell you about:
      • Team creation
      • Team deletion
      • Added channel
      • Changed setting
  14. Get familiar with the Security and Compliance Centre, so you can check that you users are following the policy.
  15. Get users to learn the Search box. E.g. Type @name in the top centre search box to start a chat with someone
  16. Check out all the add ins and connectors – there are many. Take a view on which add value and provide guidance to staff on these.teams connectors
  17. Consider writing Flows to inject messages, updates and even email into the Chat streams in channels – you can probably reduce email by 10% or more
  18. ‘Favourite’ teams and channels for people, so that they can find the Areas they want more easily.
    • Try to keep the number of Favourites to no more than a dozen
    • Link to Teams Areas from SharePoint (and anywhere else relevant), especially for less commonly used Teams
  19. Consider keeping a log /directory of all your Areas.
  20. If you have less than 1000 staff, create an All Staff Area and use it for general communications etc. similar to how you might have with a discussion group or Yammer. Consider adding your Company News feed to a tab or as a channel
  21. Create a Feedback channel in the All Staff Area
  22. Decline to travel to meetings; suggest that they can be done via Teams instead.
    1. Ensure the New Teams Meeting button is enabled in Outlook for 1-click online meeting creation.
    2. Do the same with your clients
    3. Ensure users have access to headsets.
    4. Consider using video too
  23. Turn off Skype for Business



Find out more:










1 Comment

Filed under Best Practice, Cloud, Collaboration, Microsoft

Microsoft Search – isn’t that just Bing?

Microsoft Search was just announced (Ignite 2018, last week in September). To be honest, when I saw the announcement, my reaction with “Hmmph. So what”
Since when I have been reflecting on it quite a bit; and showing Microsoft Search to various people. I’m now shifted from “Hmmph” to “Gosh! Hmmm, that could really work”. Everyone I have shown it to has said it’s good – even my technosceptical wife.

Ordinary users rarely think to go to their intranet to look for things – they jump straight to a search engine – almost always Google

Microsoft Search, like so many good ideas, is a simple concept. Ordinary users rarely think to go to their intranet to look for things – they jump straight to a search engine – almost always Google. Diverging, for a moment, there is a well-worn process that architects etc. use when deciding where to lay paths and pavements; they wait a few months and then put them where the grass has been flattened by heavy footfall. Microsoft are doing the same – instead of plaintively pleading with people to go to where Microsoft would like them to be, they are putting the things tools where the people are already going – it seems that Microsoft have learned, at last, that they can’t dictate behaviour to end users. With Microsoft Search, they are putting corporate search where the users are, rather than trying to force users to the intranet, where the company search has traditionally lived. Microsoft Search cleverly returns results from across Office 365 as part of the ordinary search engine results. The caveat is that the search engine has to be Bing, not Google (more on that later).

Microsoft are putting corporate search where the users are, rather than trying to force users to the intranet

For the user, it’s as simple as opening a browser (probably Chrome or Edge) and typing their search into the search box or address bar. At the top of the results they get are items from across their Office 365, including SharePoint, OneDrive, Yammer (and soon to include Teams, Stream etc.). There are even some fancy recommendations, branding and the ability to limit the search to files, sites or conversations. The only thing the user really needs to do is ensure that they have logged in to the browser with their work credentials, and presumably this is something which can be automated by canny IT departments.

For the IT department, there’s a little bit to do but is not too onerous. They need to set up Microsoft Search from the admin portal, which is available via the Office 365 admin centre. From here it’s possible to apply a branded logo and colour, as well as provide some search suggestions to get people used to the concept. There other neat features here, including the ability to build out question-and-answer sets (which is almost certainly using Azure QnA Maker), define bookmarks for recommended links (and import SharePoint best bets where this concept originates), alongside the expected management capabilities.
It is also likely that IT will want to push out Bing as the default search engine using group policy. There’s probably a piece of work to do to reassure users and management that this is not exposing corporate information to the Internet.

But… Bing!
There’s bound to be a few raised eyebrows at the use of Bing. However, the choice of Bing versus Google is a bit like being forced to choose between a Maserati and Ferrari; they’re both really rather good, even if you’d rather have the Ferrari.
Let’s think about this for a moment. Microsoft have lost the battle against Google on the personal desktop, even though Bing is a perfectly adequate engine. But in the corporate space they might just win it with this move; there’s no real downside to this choice of search engine and the ability to present corporate content is a huge win. Organisations actively need their users to be accessing curated and governed company knowledge rather than finding out things from the Internet.  They don’t even have to force users to use Edge if they don’t want to (though it has become an excellent browser over the last year); every decent browser lets you define the default search engine.


  • Users will love it, so they will use it. It’s quick, doesn’t require any training and shows user relevant results that they would otherwise miss. Plus it takes zero effort or knowhow.
  • It increases the chance of users finding what they need, while improving compliance and governance.
  • It provides richer results than just an Internet search, including finding people and conversations, not just documents; this can include specific bookmarked content and frequently asked questions. It’s probably better than their current intranet search, in fact.

What of the intranet?

If we place this release alongside the rapid rise of Microsoft Teams (allegedly the fastest adopted application Microsoft has ever built) and the rapid shift to mobile apps, and it does beg the question of the role of an intranet in general and the value of the intranet home page in particular ( especially as it relates to SharePoint).
A decent intranet attempts to pack search, news, applications and interactive content onto the homepage, while team and departmental collaboration sites lurk within the structure. However, modern SharePoint Online sites seamlessly push news content to the SharePoint mobile app, ready to be consumed by users on their Android or Apple phone. The recently promised option to add custom applications into Microsoft Teams (which is equally happy on the desktop or the mobile) means that the majority of users may never need to touch the browser-based intranet, other than via the mobile application. This means that they will never see the homepage.
It may take a few years, but is now easy to imagine a future where the current concepts of an intranet are genuinely thing of the past; users will simply have no need to go to a ‘stuffy intranet home page’ for the vast majority of activity, they will be using Teams for collaboration, interaction and business process (perhaps supported by custom Power Apps) and consuming content via the SharePoint app (until it gets called something else). The role of the SharePoint partner or internal developer will change it again, with even more emphasis on strong information architecture to support intelligent content and coordinate the rich ecosystem of content, communication, collaboration, business process and people. Advanced content management will underpin everything, but the user experience will happen somewhere else entirely.
You can find out more about Microsoft Search here and on the site Bing or set it up via your  Admin Portal if you are already in Office 365 organisation.

Leave a comment

Filed under Cloud, Content management, Innovation, Microsoft, Office 365, Search, UI and UX