I get this question a lot: Are you using out-of-the-box features in SharePoint? The answer is always the same: No. And then the client cries out in pain.
Before you cry out, however, let me instead explain to you why the term out-of-the-box makes no sense in a SharePoint context.
In a traditional software setting, using out-of-the-box features means that one reuses components that come with the platform rather than creating new components. The major difference, however, is that SharePoint is the platform, not the finished components.
Out-of-the-box in SharePoint often refers to some of the sample implementations that Microsoft ships with SharePoint, such as the team site, publishing sites, enterprise wikis, and so on. They may also refer to the default list definitions, workflows, page layouts, or forms. These are, with the exception of the simplest and smallest of installations, rarely what you as a client want.
The power of SharePoint is its incredible flexibility in creating exactly what you want. In traditional software, you need to learn the software and adapt your way of working to what that software offers. In SharePoint, however, we as developers instead ask you how you want to work and then adapt SharePoint to support that way of working.
Using the out-of-the-box functionality kills that flexibility and forces you do adapt the way you work to what someone in Redmond thought of in his or her lunch break one day.
For example, you may want to share contacts with your team members, but you don’t need anything more than the name, email, and telephone number of your contacts. The out-of-the-box contact list contains tons of additional information, and while it wont hurt you to have all those extra columns, they serve no purpose either, and clutters up your screen.
You can take the out-of-the-box contact list and remove all the columns you don’t need, but then you’re not longer using out-of-the-box functionality and, ask any seasoned SharePoint developer, it’s a lot easier to just create the contact list you want than try to modify an existing list in a supportable manner.
I’ll explain this in another way, using a favorite analogy of mine: building houses. SharePoint is nothing more than the tools you use to build a house. You get hammers, nails, screwdrivers, bow saws, and whatever one uses to build houses. Using those tools, SharePoint developers can build exactly the house you want.
Now, out-of-the-box in this case would be a pre-made house that someone in Redmond has built using the SharePoint tools. The pre-made, out-of-the-box house has a certain numbers of rooms and floors, a certain type of windows and a certain shape.
That house is likely not going to be the house you want; you may want more rooms, a different organization of the floors, perhaps different windows, or even change the layout of the house. In fact, if what you want is that exact house, you’re much better off just renting one of them (in SharePoint terms, use a hosted site provider) and do your minor changes such as swapping the carpet or setting up a few lamps.
SharePoint developers in this analogy are house builders. We know the tools but not what you want us to build. That is why you tell us how you want your house and we build that house. If you ask us to use the pre-made rooms or walls that you get out-of-the-box, we’ll likely tell you that it’s a bad idea.
Another concern for many clients is supportability, meaning that Microsoft will give you support for your solution. The secret here, though, is that Microsoft supports the tools but may not necessarily support out-of-the-box functionality. You can easily create unsupported scenarios with the out-of-the-box functionality. However, as long as your developer knows his or her trade, they will use supported methods and make sure that Microsoft can support your finished building.
So, if you want out-of-the-box, go get it; you don’t need my help. If you want to get a solution that does what you want, however, I’d be happy to create that for you, but it will likely not be anything out-of-the-box.
I hope you now realize why using out-of-the-box functionality makes no sense in SharePoint and don’t ask me to use out-of-the-box functionality. If using out-of-the-box functionality is a good idea, then it is far more likely that I’ll tell you why it is a good idea 🙂
Update: It seems that there is some… ambiguity… about what out-of-the-box means. Funny thing is that redefining what out-of-the-box means doesn’t really change the argument. Even if one is to say that modifying a contact list still is out-of-the-box, I’m trying to say that it doesn’t make sense, because modifying an out-of-the-box list is a stupid idea. I’ll post a separate post, more technical, to explain why. I want this post to remain non-technical because I actually wrote it when a client asked me to use out-of-the-box as much as possible because of supportability.
Also, someone stated that I’m actually using some out-of-the-box features all the time, and I agree. In fact, of the out-of-the-box features I use a lot, I find the custom list, the Item content type, and sometimes some of the navigation elements to be quite useful. As proofs of concept, I even often include the basic default.master or the STS default.aspx, mostly to have some user interface until the designers can work their magic.
Beyond that, I generally chuck most of what ships out-of-the-box out-of-the-window and use SharePoint not as a ‘mom, see what I can do’ product but rather as a business productivity enabler.
Found this article valuable? Want to show your appreciation? Here are some options:
a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.
b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!