The other day I decided to start a power user best practice series. I started with site columns and now the next logical step is content types. I have found that many times experienced users don’t realise the importance of a properly setup content type. Because of this, they often are recreating the same data, having to redo the content types and in some cases blow them away and start over (both of which are a real pain if the CT is already being used). The intent of this post is to cover the best ways to create your content types.
So today I am starting a new series on SharePoint Best Practices. This may seem like a fairly simple topic but, I have come to learn that it is an important one. I am not talking about best practices in setting up and configuring SharePoint or how to best develop a solution in SharePoint. I am instead wanting to discuss best practices in your day to day usage of SharePoint. Too many times I have worked with experienced clients that have a decent knowledge of how to do things in SharePoint, but don’t think of the little things that make these best practices. This is where this series is coming from. Today I am going to cover site columns.
All too often when building workflows in SharePoint Designer there is a need to pause the workflow for a duration of time, or while waiting for values to change within SharePoint list\library. Microsoft has provided methods or actions within a workflow to accommodate this for quite some time. The method to accomplish while similar between versions has changed with the latest iteration of SharePoint Designer. For this reason I wanted to discuss waiting in a SharePoint Designer 2013 workflow today. I know that most are now moving to SharePoint 2016 or SharePoint online, but while Microsoft has released newer versions of SharePoint, it hasn’t released a new version of Designer since 2013. So whether you are on SharePoint 2013 or a later version, this post is relevant for the foreseeable future.
I am blogging to you right now from Denver, Colorado where I have had the honour of speaking at the SharePoint Fest conference there. I also was speaking at the SharePoint Fest conference in Washington, DC where I received some good constructive feedback. With that in mind I completely revamped my slide deck and approach to the presentation. I am just writing this post after the first session with the revised deck. It went awesome. I had a great group of people in my session and a packed room. I think the slides revamp was great. Thanks SharePoint Fest DC!!
You can access my new slides here:
Thanks for reading!
Recently at my client site (I have a lot of posts that start this way) we have been getting more and more requests for groups that want to bring higher amounts of data into SharePoint. These requests are really pushing the limits of SharePoint Storage thresholds. So I started looking into the ways that we can get around that. Our thought was that since Microsoft recently announced being able to handle 25TB of data for SharePoint Online Site Collections. We should be able to easily handle the 4TB ceiling in our on-prem environment.
Update: I wrote another blog post concerning this where I go into greater detail on how to test if your environment can go beyond the 200GB threshold and the results of a test I did. You can view that information here.
SharePoint Database Size Limits
The limitations of SharePoint’s content databases are pretty well documented here: https://technet.microsoft.com/en-CA/library/cc262787.aspx#ContentDB. But in a nutshell you want to keep your content databases below 200GB. The same document actually suggests splitting out your site collections if the content DB reached more than 100GB. This would be to allow for growth within the sites.
But what if it’s a single site collection within that database? This now means you should consider branching off the site collection into multiple site collections. For example, create an archive site collection to house data that is no longer actively updated or used. Likely this will cut down on your data usage a great deal. You will have to migrate the data in order to do it, but it is a necessary evil to save on space.