SharePoint Document Management

SharePoint Document Management

Why you should never attach documents in a SharePoint list

no thumb

I see this happening again and again – users attach documents in a SharePoint list. Yes, you can do it – but that is not what SharePoint list was designed for. It is like making pancakes with an iron. As a matter of fact – there are some very strong reasons for you not to continue this poor business practice. Let me explain.

Just to set the stage for what I am talking about, in SharePoint, there is a concept of a list and a library. In case you require clarification on the difference between the two, check out this post.

SharePoint Document Library, by default, allows to store and organize, you guessed it, documents (files). If you have a document to store – you would just upload one (or many) into a document library. And of course, you can organize them via folders or metadata.

SharePoint List, on another hand, is used for storing non-document information (think of it as Excel in SharePoint) – table of rows and columns of some information. This could be a list of events, properties, clients, projects, tasks, etc.

The thing is that SharePoint lists also allow you to attach documents (files) to a given list item. Say you have a list of projects or clients in a SharePoint list, you can attach the file(s) to a given item.attach documents in a SharePoint list

Attachment option in a “classical” SharePoint List

attach documents in a SharePoint list

Attachment option in a “modern” SharePoint List

Eventually, you can also end up with an item that has multiple attachments associated with it.

attach documents in a SharePoint list

Now that we are clear on the difference and the mechanism of the two, let me explain why you should not use SharePoint lists to store attachments.


By default, SharePoint list is not a document library and, as a result, lacks all the document management features of a document library, like versioningcheck-in/check-outco-authoringability to open and edit documents in the browser, etc.


While you do have a version history functionality on the item in the list itself (if you enable versioning on the list), it does not carry over to the attached files. For example, if you have an item at Version 1 with two attachments, then make a change to an item and delete one of the attachments, if you decide to go back (restore) Version 1 again, it will only have 1 attachment, not the 2 it had originally. You would need to remember to go to the Recycle Bin and restore deleted attachments from there!


Since attachments just sit together attached to an item, there is no way to organize them in folders or apply file-specific metadata (like you can in the document library). I hope this is obvious!

attach documents in a SharePoint list


This depends on whether you use classical SharePoint list or a modern one. In classical SharePoint custom lists and other “classical” web parts like Calendar, TasksIssuesAnnouncements, etc, you can only attach one file at a time. With the modern SharePoint lists (think Custom List), this is not an issue, you can upload many at once, no problem.

attach documents in a SharePoint list


This other reason is here because of my loyal blog follower and fellow SharePoint Consultant Ellen van Aken from Holland. She advised me about it once she saw an original post, so I added it here now. That has got to be one of the primary reasons against list attachments – the fact that those attachments are ignored by search! Let me explain.

When you upload documents to a document library, the SharePoint search engine crawls the documents and indexes them (just like Google does), so you can later search by keyword and find the documents in your site or library. Well, if you upload your documents as attachments into a list item, none of this happens! They are just ignored by search! So, whether you conduct a search at a list level or site level – these documents are “invisible” to SharePoint Search. The search will only find text and metadata you have on a SharePoint list itself (columns). Oy Vey!


Option 1: Training

Education, my friend, education. Knowledge is power! While you can turn off attachments on a list (like I describe below), you won’t remember to do it on every single list you have in your environment. So make sure to properly educate your users (share this post with them) and educate and train them before they screw it up for you!

Option 2: Turn off attachments in a list

It is very easy to disable attachments on a SharePoint list. And something I do every time I configure a list for my clients. To disable attachments in a list:

  1. Go to List Settings > Advanced Settings
  2. Scroll to the middle of the page to Attachments section and choose Disabled radio button
  3. Click OK


Just like with any other situation in life, it depends. In most cases, it would be wise to not use SharePoint lists for storing files and working documents. However, there are certain situations where this might be beneficial. Say, for example, you have built a Help Desk system in SharePoint, and it is, of course, a SharePoint list (say, Issues log). So when users submit a ticket, you might want them to also attach screenshots to help IT solve the helpdesk request. So leave attachments on in that case.

However, anytime you need to store MS Office documents or other files for say a client or a project, and especially when you wish to store multiple documents, you are better off using good old SharePoint document libraries.


Use Document Sets!

In case you have one-to-many sort of relationship, where, say, you have a client list and some documents that need to be associated with a client, the option I would highly recommend is Document Set.

Document Set functionality allows you to create folder level metadata (your SharePoint list metadata essentially) and attach files to each document set (i.e., Client). In a way, you end up with a folder (document set) for each client or project and then corresponding documents inside of each folder. On top of that, all files stored within a document set inherit metadata from the folder! So it is almost like having a SharePoint List with attachments, except, done properly!

List of folders (document sets) with metadata (in place of a SharePoint List metadata)

Contents of a Document Set. Files are organized using metadata and benefit from all the available document management capabilities

If you want to familiarize yourself with the magic of document sets – check out this post which explains what they are all about and how to set them up.

read more
SharePoint Document Management

4 ways to edit document metadata in SharePoint

no thumb

If you follow my blog,  you probably know by now that I am a huge advocate of metadata. One of the most frequent complaints I hear about it is that (and I quote) “It is a @#$% pain to tag documents with metadata every time they are uploaded to SharePoint.” I could not disagree more!So with this post, I would like to provide you with four convenient options to tag documents and edit document metadata in SharePoint. Choose one that works best for you, and please tell those metadata drama queens who still complain!


The first option is the classic one and most straightforward one that you can get. You upload or drag and drop a document to a SharePoint document library and then tag it along, in the Document Information Panel window. Your window might look different depending on what version of SharePoint you use.

In older versions of SharePoint or SharePoint 2013/2016 on premises, you get the classic library experience, so your Document Information Panel looks like this:

edit document metadata in SharePoint

With SharePoint Online you can still get classic experience for a document library, but hopefully, you run a modern document library experience, so your Document Information Panel looks like this (accessible when you click “i” in the upper-right-hand-corner of a document library):

edit document metadata in SharePoint


What if you want to tag multiple documents at once? In modern libraries we now have a Bulk Editoption. The way it works, you select multiple files and choose Document Information Panel, just like above, and you can then apply properties to many documents at once.

It is important to note that this option is not available with classical libraries. Just modern ones. But what if you need to tag multiple documents in the classical library? Keep reading!


There is another way to tag many documents at once and that is via Quick Edit feature. I outlined this in great detail in this post. This feature is available in both classical and modern libraries!

edit document metadata in SharePoint

edit document metadata in SharePoint


Did you know that you can tag your documents completely outside of SharePoint? You can tag them right inside of the Office documents (Word, Excel, PowerPoint) and once tagged – just upload back to SharePoint. This is another great option for those suffering from metadata tagging fatigue. I outlined the step-by-step instructions on how to do this in this post.

edit document metadata in SharePoint

read more
SharePoint Document Management

2 ways to make SharePoint document search as easy as shopping online

no thumb

Do you love shopping online? I do! The major reason – within a few clicks I can usually find what I am looking for, without spending days sifting through the shelves and driving to stores. What makes online shopping experience awesome is the ability to filter through various criteria. Amazon® is one of the most famous and brightest examples. As soon as you type an item into a search box, you get a large selection of filters that can help you pinpoint the very item you are looking for. For example, if you are searching for shoes on Amazon® (my favorite hobby 🙂 ), you can filter search results bysize, color, brand, price, reviews, etc. SharePoint document search should be no different.

With this blog post, I would like to demonstrate how you can achieve a nearly identical experience when searching for documents in your SharePoint document library. One big assumption here is that you are using metadata to categorize your documents and not folders.


Metadata navigation is a feature that surfaces up metadata columns on the left-hand-side of the document library, nearly simulating an Amazon® search experience. I have documented step-by-step instructions on how to configure and set it up in this post.

SharePoint document search

NOTE: This option is only available to those with SharePoint on-premises. If you are in SharePoint Online (Office 365), you need to switch your modern document library into a classical experience in order for metadata navigation to be available.


Another way to filter documents via metadata is via the new Filter icon. It is a new feature within the new document libraries. While you can filter any metadata columns in “the view” using column headers, filter icon allows you for a sleeker filtering experience, almost identical to online shopping one.

SharePoint document search

To filter, just click on the icon and choose particular filters and it will filter results accordingly!

One other important thing to note is that filter icon is not only available on modern document libraries, but also on modern custom lists as shown below!

Both of the options above provide a nice and intuitive user experience and will allow your users to find docs and content in a heartbeat while improving and promoting the user adoption of SharePoint in your organization.

read more
SharePoint Document Management

How to hide folders from a document library

no thumb

Did you know you could hide folders from the document library? Let’s say you have a library with pretty complicated folder structure. Maybe you added some metadata columns to it to help you organize it better, or maybe you are just so sick of folders, you want to hide them all and essentially flatten the structure and view just the files. Whatever the reason is, below is a quick way to hide folders from the library.

Please note that I am not talking about restricting user access to certain folders here. This post is about suppressing the folders – making them invisible (but leaving the contents intact).


  1. Go ahead and create a new view called “No Folders View
  2. Scroll down all the way to Folders section and choose “Show all items without folders” radio buttonhide foldershide folders
  3. Click OK

The library will now display all the documents without the folders (folders suppressed)


This might be a great trick to use if you have your folder library that you migrated over to SharePoint and now converted it to metadata. By hiding the folders, you will now benefit from metadata views and filtering, just like a normal metadata document library.

read more
SharePoint Document Management

Stop mapping SharePoint Document Libraries as a network drive!

no thumb

I see this happening over and over again. Companies purchase Office 365 subscription, create a single site in SharePoint with a single document library, migrate their whole file share into that single library, map it as a network drive and call the project complete. What usually follows is a dismal user experience from a performance standpoint and badmouthing of SharePoint and anyone who made a decision to migrate to Office 365. If this sounds familiar – keep reading.

I have written a post previously where I cautioned against using SharePoint as a file share. When you map a SharePoint document library, you essentially say:

“We want to collaborate the same way we did for the last 20 years”

If this is your wish, so be it, but I would argue against using SharePoint for this purpose. Because you will fail miserably. That’s not what SharePoint was designed for. Below I would like to present few reasons why, in my opinion, you should not create any mapped drives with SharePoint.


Sooner or later you will encounter SharePoint technical limitations.

  • 5,000 item limit. Read here to learn more
  • URL length. If you have a very deep folder hierarchy, you will encounter it one day. Click here to learn more.
  • Performance. As your library grows in size, you will see degraded performance


The best practice in SharePoint is to create many sites and many libraries as you split content by function and security. Even on a single site, you might have one, two, four document libraries. How will you handle this with mappings? Are you really looking to create like twenty mappings?  🙄

mapping SharePoint Document Libraries


As I have written previously, SharePoint search is quite robust. The new, modern search is just awesome! Search in SharePoint goes against content within the document as well as metadata. When you search a mapped drive, you are using the regular Windows Explorer search. Should I even say more here…


If you map a drive in SharePoint, you are missing big time on metadata. There is no metadata in Windows Explorer. You have to access your files via SharePoint to be able to tag, search and filter based on metadata.


Versioning, in my opinion, is one of SharePoint strongest features. Ability to see and track changes, ability to access and restore previous versions brings collaboration to a whole new level. That is if you use SharePoint. If you map a drive in SharePoint – you won’t have access to these features in Windows Explorer.


Classical library experience that we had with all the old versions of SharePoint was pretty boring and did not allow for trivial commands like Copy and Move. Now that we have Modern Library experience in SharePoint Online, you can do the same things like you used to in Windows Explorer. You can copy and move files, for example, between folders, sites, and libraries right in the browser. So all the reasons that prompted you to work in Windows Explorer are no longer relevant.


One of the reasons for using mapped drives is the fact that it is easier to do Save As from MS Office documents to your C: Drive. With the recent update to MS Office, this limitation is no longer there, and you can easily save files from MS Office directly to SharePoint. Click here to learn more.


“Intelligence is the ability

to adapt to change”

— Professor Stephen Hawking (1942 – 2018)


If none of the above reasons convinced you and you truly want to work with files like in 1995, may I suggest the Sync option? You can always sync your files to your desktop using the new OneDrive for Business sync client. While I am not a huge fan of sync, it does the job and makes the library or certain files and folders available on your desktop if need be.

Hope you found these reasons convincing enough to drop the old habit and move yourself to the 21st century. You don’t use telegrams anymore because we have email, so I suggest that you also work with documents using SharePoint browser experience instead of the outdated file share approach by mapping SharePoint document libraries.

read more
SharePoint Document Management

Document type vs File type vs Content type


With this post, I would like to clarify some SharePoint terminology. Call me a perfectionist, but I want to get the record straight, once and for all. I see the terms like file type, content type and document type used interchangeably with SharePoint, though they all mean different things. Let me explain.


File type refers to the application of the file. For example, Word, Excel, PowerPoint, PDF or JPG are all different file types. Essentially, I am talking about file extensions here: .doc, .xls, .pdf, etc. Once uploaded to SharePoint, you can quickly see the extension (file type) using the file type column. I explained this in greater detail here.

Document type vs File type vs Content type


The Content type is a formal name for functionality/feature available in SharePoint that allows organizing content into categories while maintaining unique metadata per content type (among other things). I explained the concept of content types here and also explained how to set one up in this post.

Document type vs File type vs Content type


Unlike the above two terms, the document type is not an official SharePoint terminology.

It is a piece of metadata that one uses to identify the document uploaded to SharePoint. For example, invoice, agenda, meeting minutes, are all different types of documents. As such, Document Type columns happens to be the most frequent custom metadata column created in any SharePoint Intranet.  Because often, whether you have a project site or department site, this column provides a great description of the document. I even published a list of some basic document types you can upload and use in your SharePoint Term Store.

Document type vs File type vs Content type

read more
SharePoint Document Management


no thumb

One category of clients I help configure SharePoint for are law firms. SharePoint makes perfect sense for the legal industry, as it allows to easily store documents in the cloud and be able to access them from outside of the office (i.e., courtroom). Additional SharePoint features, like versioning and metadata, allow for a very robust management of legal documents, court or client correspondence. I worked with many attorneys in my life who helped me with life’s various legal battles, so I am very familiar with their lifestyle and processes. I like creating case portals for legal firms, since this is the only time when I talk to an attorney and they have to pay me for services, and not the other way around.  🙂

So here are the options available to law firms that wish to manage and organize case documents in SharePoint (using Out of the Box functionality).


This option is no different than what probably most attorneys currently do on their network drives. Essentially, you would provision one site in SharePoint with one library and organize all cases in respective folders, with a folder for each case + lots of subfolders underneath.

Limitations of folders in SharePoint are well known and documented, and I myself published a post on the topic.

Also, I see the following possible issues with the above approach:

  • Not scalable
  • Pain to archive old cases
  • Seach will become challenging as the library grows exponentially in size over time
  • Unique security per case/folder (if necessary) might not be easy to set up

manage and organize case documents in SharePoint


This option mitigates most of the concerns from Option 1 and is best when you need to manage more than just client documents. Maybe you need to track case events, tasks or store contact info. If this is the case, SharePoint sites are the way to go. This is very similar to project/team site approach, where for each client you would provision a whole separate site. While this option does carry some overhead, in terms of site creation and security configuration, it is most scalable one.

Each case gets its own site and can contain a number of document libraries, other web parts (calendar, task list) to manage a given case. Moreover, you can create a template for each case and provision new sites based on the certain (standard) look and feel – this is huge from the consistency standpoint. Each site can also have its own security (in case you represent VIPs and case needs to be confidential).

manage and organize case documents in SharePoint

In addition to a Case Site Template, you would also have a Case Dashboard – a site that details all the ongoing cases in a SharePoint list. This will allow for easy case access and tracking.  When the case is completed, you can mark it as such on the dashboard and hide from the view.

manage and organize case documents in SharePoint


Another option that is becoming very popular with law firms is the Office 365 Groups option. This stems from the requirement that emails often sent to attorneys contain information often pertinent to the legal case and need to be stored accordingly (and be easily accessible). While having all the other traits of a SharePoint Site, Office 365 groups also have an email conversation feature, which allows emails sent to that Office 365 distribution list be stored as part of Office 365 Group. This is a huge advantage, in comparison to classical SharePoint team site.

Moreover, Office 365 Groups ecosystem, provides other tools, like Planner for Task Management and Teams for chat/communication capabilities. I have not seen these being used that much by attorneys just yet, but do think it is a matter of time before these new tools will be adopted.


The option that is also very popular with attorneys is Document Sets. At the end of the day, attorneys need to organize various case documentation. Document Sets have some unique features which make them perfect for attorneys:

  • Folder (Document Set) for each client
  • Folder-level metadata. In our example, it will be case-level metadata, like Client Name, Attorney/Paralegal name, Opposing attorney name, type of case (i.e., divorce, criminal, medical malpractice, etc.)
  • File-level metadata. Additional metadata can be set at a file level, allowing attorneys to segregate files by document type (i.e., Client correspondence/materials, Court notices, etc.)

The screenshot above shows a Document Set in the context of a project; Legal Case Document Set would look similar, with case-level metadata at the top and documents at the bottom.


Any of these options are valid, and I have seen all four used. My favorite one is Option 2. It is scalable, allows to templatize the case site, and case dashboard (list) is a bonus! You can’t go wrong with it!

read more
SharePoint Document Management

How to prevent team site members from editing SharePoint pages


In this post, I am going to describe how to get around a pretty damaging issue in SharePoint Sites. It is the ability of regular members of the site to edit pages, including the homepage of the site. In SharePoint, pages are treated just like any other content (documents, events, etc.). This means that if the users have Edit or Contribute permission level (those in Members Group), not only these users can add/edit/delete documents from a document library, but they can also modify the pages!

Now, in some cases, this might not necessarily be a bad thing. If the site pages are used as a wiki, that’s exactly what we want the users to do – be able to edit content on the pages! However, (as is the case in most instances), if I am, say, a Site Owner of a department or project site, the last thing I want is my members be able to @#$% up the homepage of the site I spent hours creating. It is one thing if Johny deletes a document from a library, it is another if Johny edits or deletes the main project or department site page and screws it up for everyone. Oops. Little Jonny is in trouble and won’t get his annual raise this year.

Now that we are clear what I am talking about, let’s see what the option are to fix this little annoyance.


If you want to prevent editing of all pages on your site – that’s easy to accomplish. All site pages on a site are stored in the Site Pages library. It is just like a document library, but just for site pages. By default, just like a document library and other web parts, it inherits security settings from the site. So if you want to prevent team members from editing the pages on a site, what you need to do is break inheritance and make this library read-only for Members Group. Here is how to do this:

  1. While on a site, click Gear Icon > Site Contents
  2. Where you see a list of contents of your site, click on Site Pages library
  3. Next, we need to break inheritance for this library from the rest of the site. To do this, click on Gear Icon > Library Settings
  4. Next, click on Permissions for this document library
  5. As you can see from the message displayed, by default, Site Pages inherit permissions from the parent (Site). That’s why by default, all regular team members can edit all pages.editing SharePoint pages
  6. To break inheritance, click on Stop Inheriting Permissions. If the warning pop-up appears, click OK
  7. Click the checkbox next to Members Group, then click on Edit User Permissions
  8. Finally, uncheck the checkbox next to Edit and check it next to Read. Click OK
  9. We are all set!editing SharePoint pages


Option 1 is easy but might not be a wise decision. That’s because when you don’t allow users to edit pages, they can no longer create or edit a wiki or add an announcement (in modern pages, every announcement is a new page – as part of News web part). So a smart thing here to do would be to prevent editing say the homepage if that is what you care most about, but not of all the other pages.

Here are the instructions on how to prevent editing of a particular page. They differ a bit depending on whether your site still uses classical pages or modern ones.

Classical pages only

  1. On the classical SharePoint page, click Page Tab > Page Permissions
  2. You will notice a familiar interface, as with Site Pages library above, except this, applies to just this 1 page. Just follow Steps 6-8 from above, and you will be golden!

Classical or modern pages

There is another way to restrict access, and you can employ it for both wiki (classical) and modern site pages.

  1. Navigate to the Site Pages library using steps from above (Gear Icon > Site Contents, then click on Site Pages library)
  2. Click the check box next to the page you want to restrict from editing, then click on little “i” in a circle, then Manage accessediting SharePoint pages
  3. Click the drop-down next to Members Group, then change Edit to View Onlyediting SharePoint pages
  4. That’s all, honey! You may now sleep well.


If the inevitable happened, and some shmuck from your team inadvertently modified the pages before you discovered this blog post, no worries. Thanks to Version History, we can easily restore the old version. Versioning on Pages works just like with the regular documents. This is how you do it:

  1. Navigate to the Site Pages library (you should know how to do this by now)
  2. Right click on the page you want to restore and click Version History
  3. You will see all the changes made to the page
  4. Click the drop-down next to the version you want to restore and click Restore
  5. If the warning pop-up appears, click OK
  6. Your page should be restored (another version created)
  7. Mazel Tov! Hope I just saved you hours of rework and swearing at your colleague.
read more
SharepointSharePoint Document Management

Why you should never delete some SharePoint elements


Yeah, for the minimalist guy like me – the topic of this post is kind of odd. If you have been following my posts, you know that I like to keep things simple. However, it is very important that you do not go overboard here with “tiding things up” and deleting everything in your path. No, I am not asking you to become a hoarder or turning your SharePoint into one large garbage bin. I am not talking about content here (files and folders) at all, but rather “technical” elements and building blocks that make up SharePoint, like columns, content types, views, lists, and libraries. There are some very strong reasons why you should never delete any of them unless you want your SharePoint to break. So with this post, I would like to convey the explanation and reasons. Consider this blog an important Public Service Announcement.

Deleting SharePoint elements carries potentially non-recoverable consequences

Below is a list of major SharePoint elements:

  • List/Library Columns
  • Site Columns
  • Site Content Types
  • Default Views
  • Default Document Library
  • Default Pages
  • Default Site Collection
  • Security Groups

Some should never be deleted. Some can be deleted if you are 100% sure that doing so won’t cause havoc. Let me explain.


There might be cases when you created a column at the list or library level and need to remove it. If you are 100% sure you no longer need it – go ahead and remove it.

never delete some SharePoint elements

However, if you are not sure whether you might need it in future again, you are better off hiding it. While the column is hidden from the users, it still exists out there in a list or library. Follow these steps to hide a column:

  1. Navigate to List or Library Settings via gear icon (if you are using modern experience). In classical, that option will be available on the web part ribbon
  2. Click on Advanced Settings
  3. Check the “Yes” radio button under Allow management of content types? Click OK at the bottom.
  4. What the previous step did was add a Content Type area in your list or library settings page. This is where you can hide the columns.
  5. Click on the Document Content Type
  6. Click on the column you want to hide. The default is Optional (visible).
    never delete some SharePoint elements
  7. Change the radio button to Hidden. Click OK
  8. That’s all! While the column still exists and can be re-surfaced anytime if need be, it is hidden from the user when they fill in the metadata.never delete some SharePoint elements


If you are setting up your columns as site columns (click here to learn more about the difference between list and site columns), you probably have seen a huge list of out of the box site columns that already exist.  It might be tempting to “clean the house” and delete them. Please don’t! These columns are core columns used in certain out of the box web parts (contact lists, etc.) and content types. So just leave them there as-is. If you need to create a site column with a name that already taken by OOTB columns, just be creative and do a unique name.

Go to Gear Icon > Site Settings > Site Columns to see what I am talking about…


Just like with Site Columns above, do not touch any out of the box site content types. For the same reasons as above.

Go to Gear Icon > Site Settings > Site Content Types to see what I am talking about…


Every list and library has default views built in. Custom List and Custom Library have All Items andAll Documents views respectively, and some other web parts have additional views as well (i.e., Tasks).

published a post on why you should never mess with a default view. So read that post, and it will explain why you should never delete or modify them. As described in that post, an alternative would be to create additional views and then make them default.


A while back, I blogged about why you should not use a default document library on a site and instead must create your own.

If you follow the above tip, the temptation then is to delete the default document library that came with the site. Please don’t! Otherwise, you will end up in a situation, just like one of my loyal blog followers, who decided to “clean the house” and ran into an issue below. Let me explain.

Here is the crux of the issue: If you happen to use a modern page experience and decide to add a document to a page (via File Viewer Web Part)…

… by default, it will upload the document to a default document library that is created with the site(Documents). However, if you happen to delete that default document library from the site, you will no longer be able to upload the document via File Viewer Web Part!!!

Likewise, if you have Office 365 Group Site, default document library is connected to MS Teams/Channels. So while I still stand by the fact that you need to create new document libraries and not use a default one, you must refrain from deleting the default document library altogether!


A page is a critical element of a SharePoint Site. A page is what displays content from your site. Every site has one at least. So resist the urge to delete all pages from a site! It is like you buy an iPhone® and break the display. Shall I say even more? Yes, you can create additional pages and you can make other pages homepages, but do not end up in a situation where you delete all of them from the Site Pages library. Otherwise, your site will fail to load properly.


While you can create and delete custom site collections – do not delete a default (root site collection)! If you are not sure what I am talking about – check out this post. If you delete a customsite collection you created – it just deletes that site collection and its content. If you delete a default site collection – it will break everything in your tenant (access to other site collections, search, OneDrive) essentially making your SharePoint unusable. You will need to either restore that default site collection from the recycle bin in the SharePoint Admin Center or provision a new one. You only need to do this if you totally messed up with customization of a default site collection and want to start from scratch.


Another element you should not delete often is a security group. As you provision new SharePoint sites and set up unique permissions, you will end up with extra three security groups for each site. True, this might mean lots of security groups if you have many sites with unique permissions, but if you delete a group, you can end up with unintended consequences. Let me clarify.

It is one thing if the security group you created is unique to the specific site. But what if you or someone else re-used the same group to set permissions on another site? Once deleted, you now mess up security/access on other sites, and users will get “Access denied” to the site now.

If you absolutely want to delete the group, check first the sites where it is used. I documented the steps in this post.

A better alternative would be to just remove the group from the site, without deleting it. When you remove groups from the site, they just lose association with the site, but otherwise, the groups still exist out there in the universe (site collection).

What about Content?

What about content, like files, folders, lists, libraries and complete sites? What if you just want to hide the stuff and not really delete it? That part is easy. All you have to do is just set permissions for that content (library or folder or the whole site). Everything in SharePoint is permission driven, so that means that if you don’t have access to something, you don’t even get to know about it or see it. I blogged about this concept here.

read more
SharePoint Document Management

4 types of document libraries in SharePoint

no thumb

Did you know that there are different types of document libraries in SharePoint? I know what you are thinking. Greg, you must be kidding me, no @#$% way! With this post, I would like to explain what they are.


The first one I will talk about is a regular document library. It is the same library you get by default as part of every single SharePoint site. It is the same document library you get when you click Add an App > Document Library. It is where you store documents in SharePoint. I blogged a lot about it before, here is one of the links.

types of document libraries in SharePoint


Another document library we have is called the Picture library. You guessed it – it is a special document library for images/photos. What makes it different from a regular document library is that it by default displays files (images) in thumbnail view – which makes sense. It also contains some built-in image specific metadata like date picture was taken, etc. I have written a separate post(Option 2) on it and highlighted its various advantages.

This is how picture library appears by default

Default metadata for Picture Library files (images)


There is another library you get by default on every single SharePoint site. It is called a Site Assets library. It is used to store all the content and files necessary for a SharePoint site to function properly (i.e. Logos, OneNote notebook, etc.). It is not a library where you will store working files and content. The library is sort of a dumping ground for everything you used to build your site – things are added to it automatically as you do this. Check out this post to learn more about the Site Assets library.

types of document libraries in SharePoint


There is another library that exists in SharePoint. As you probably already guessed from its name, it is a special library for pages! All the pages you modify or create as part of your SharePoint site – they are all stored in here. To get a better understanding of the difference between a site and a page – click here. You can’t upload any documents into this library.

How to access or add new document libraries?

To see what you got on your site or to add new libraries, click Gear Icon > Site contents

You will then see something that looks like the image below.

Technically speaking, there are other types of libraries that exist, but they are used in very rare occasions and usually are just used for a very specific purpose/types of sites. Let’s keep our life simple, shall we?

read more
1 2 3
Page 3 of 3