This blog post was posted on 31st January, 2017
SharePoint is a lot like Lego. Similar to the world’s most popular toy, when you shake it out the box for the first time, you have a set of instructions, telling you how to construct the product in a certain way. Now, you can, of course, follow those instructions page-by-page. Or you open up a huge amount of flexibility and build it differently. You are able to add ‘building blocks’ onto your environment to build it in a way that’s most suitable to you.
In itself, SharePoint customization is not a bad thing. However, just like with Lego, some customizations will make the environment even more useful and relevant for your company. Others have the potential to turn the platform into a confusing mess. So, what common customization mistakes do companies make when trying to extend and enhance the platform. And even more importantly: what can you do to avoid them?
Take a look on how to manage SharePoint solutions and environments
The five most common SharePoint customization mistakes
There are many reasons that companies make mistakes when trying to build SharePoint customizations: from simply not understanding the product to using code analysis tools that don’t tell them about problems. SharePoint customization mistakes can result in downtime, corrupted files and permanently deleted documents, security and much more. With countless reports highlighting the enormous cost of downtime, it is essential that your business avoids these common SharePoint customization mistakes.
1. Editing master pages without due care
Master Pages in SharePoint can be customized to change the entire look and feel of a SharePoint environment. This can be desirable, yet simple errors in your code can cascade right down throughout your lists and libraries. Without taking the right precautions, colleagues can wreak havoc on your environment – and it can be tough to find the source of your problems. Microsoft can update master pages through its product updates especially in SharePoint Online. So if and when that happens, your customizations may stop working or simply disappear altogether.
Make sure you: don’t make changes to default files – save your changes under a new file name and only deploy when you’re happy. Also, use a version control system so that, if your changes do make a mess, you can always revert. Finally, if you decide to create your own master pages, you assume certain functionality (components, logos, etc.) will be present. But if Microsoft changes this functionality between different versions of SharePoint, it might rendering your master page useless.
Nevertheless, the current recommendation is to avoid customizing master pages entirely and use other ways like alternate CSS or themes. Granted that this limits the possibilities a bit, but will allow you to minimize the risk of things breaking unexpectedly while improving maintainability.
2. Introducing new web parts
As with everything in this list, new web parts (Full trust model), app parts (Add-in model) or client parts (SPFx) in themselves are not bad; they can add great new functionality and let you interact with data in new and dynamic ways. However, a web part can also bring your whole SharePoint farm down or affect the usability or accessibility of your SharePoint online tenant if the code underlying has not been tested correctly. So it pays to be precise.
Make sure you: thoroughly test any new code against best practice rules and recommendations, it’s crucial. In our 2016 SharePoint and Office 365 industry report, we found that Web Parts were the most popular type of customizations found in Office 365 and SharePoint environments with 63%.
3. Rewriting SharePoint functionality from scratch
Developers are regularly asked to introduce a new feature to SharePoint. Often, however, SharePoint already has a built-in feature that is very similar and can do much the same thing. Rebuilding something that Microsoft themselves has built seems unproductive. Also, your company’s feature is far more likely to contain bugs simply because it will have been tested by far fewer people.
Make sure you: avoid building new features unless entirely necessary. Very often, you can just extend and enhance what is already included in SharePoint in less time and at a lower cost.
4. Using SharePoint Designer in a production environment
SharePoint Designer allows less experienced SharePoint administrators and tech-savvy business users easy access. It allows them to make changes to the centrally deployed and maintained files (eg. master pages, page layouts, pages, forms) stored in a sites library creating copies of those files in the SharePoint database. The result: changing or upgrading those files is near to impossible centrally without manual fixes, given that you actually know who modified which files and where.
Make sure you: restrict access to things like SharePoint designer for only those that need it. Even better: restrict it entirely for everyone and enforce best practices when deploying code (always write your code in a development environment and implement a controlled and reproducible deployment process.).
5. Being too relaxed with permissions to customize
A faulty customization can result in a huge amount of wasted time and money. Therefore, only SharePoint administrators should be allowed to apply anything beyond the most minor changes to your environment.
Make sure you: regularly review your current permissions policy, and decide who can and can’t make changes.
Avoid mistakes; save time and money
Minor SharePoint customization mistakes will result in wasted time fixing problems and perhaps a couple of corrupted files. However, major customizations can, if not reviewed and tested properly, result in enormous damage to SharePoint environments. It can take days, even weeks, to resolve some of the issues caused by SharePoint customizations. This could lead to your organization hemorrhaging cash and losing huge amounts of time and productivity.
There is no single solution to avoiding the common SharePoint customization mistakes. However, by combining best practice, policy and the right tools, you can minimize the risks involved in SharePoint customization.
Whether created by the development team or business users, applications and customizations are often the root cause of poor SharePoint health. Run the free Rencore SharePoint Applications Health Check App on-premises or online to find issues in your SharePoint applications. For more information and how to download, click the button below.
