Codementor Events

The Ultimate Shortlist of SharePoint Customization Don’ts

Published Jun 17, 2019
The Ultimate Shortlist of SharePoint Customization Don’ts

From light branding through to radical redesign, customization is almost a ubiquitous practice among companies using SharePoint. But since the arrival of the cloud variant (SharePoint Online) and its integration with Office 365, it has become trickier to tailor the product without undesirable consequences.
That’s not to say that you cannot, or should not, customize SharePoint—only that it is more critical than ever to follow best practices and avoid some of the die-hard methods that can leave your project vulnerable to performance, user adoption, and technical problems.
In case your development team is unaware of these limitations, our SharePoint consultants compiled the following shortlist of customization don’ts for you to stick to when adapting the solution to your organization’s specifics.

DON’T Underestimate the Drawbacks of SharePoint Designer

Some tools for SharePoint development and customization are in their heyday and work just fine, but some are well past their best-before date. SharePoint Designer is one of the latter.
If soldiering on with defunct customization software is not, in itself, a cardinal sin, there are two areas in the use of SharePoint Designer that you should undoubtedly avoid.

1. Using SharePoint Designer in Production Environments

The first of these worst practices is to use SharePoint Designer in the production environment or, worse still, to allow business users to do so. While the software might originally have been intended for non-developers to customize SharePoint, letting them use it for that purpose today is tantamount to self-induced sabotage of your SharePoint platform.

2. Using SharePoint Designer to Edit Pages

The other bad idea is to use SharePoint Designer for editing pages. A better approach is to use a Script Editor Web Part to insert scripts into a page. Although, for SharePoint's modern sites and pages you will need to build a client-side web part to do this. At the same time, if you have no other way rather than to use SharePoint Designer to change page layouts, create a new page layout instead of editing an existing one.
Ideally, though, if you can prevent your team from using SharePoint Designer, do so. Its indiscriminate use can create problems with SharePoint maintenance and upgrades, ruin the results of your branding efforts, and even break the user interface.

DON’T Use Master Page Editing as a Default Customization Solution

While it’s true that master page editing is the most flexible method of customizing SharePoint’s look and feel, it's also an approach fraught with risks, therefore needing rigorous control. Unless you’re confident that you have a version-control system in place which will keep things tidy, it’s better to avoid editing master pages and adding script references to them.
For example, when you customize SharePoint by referencing scripts in master pages, you must ensure that whenever someone alters a script, they also update and republish the relevant master page. Failure to carry out these actions might result in malfunctions unnoticed by the developer who changed the script, because, for him or her, everything will seem to be working correctly.

Alternatives to Master Page Editing

A much more manageable way to reference scripts is to create a custom action, enabling you to reference them across your entire site (or sites) using ScriptLinks, without placing them in master pages. You can use this method both in SharePoint Server and SharePoint Online.
Another issue is the tendency of Microsoft product updates to change functionality in ways that impact master pages. After such updates, it’s very likely that your customizations will no longer work or be deleted completely. As adaptable as the master page editing practice is, your SharePoint solution will be less vulnerable to problems if you use alternative methods of design and branding, like themes or alternate CSS.
You can also consider using SharePoint Design Manager to tweak SharePoint master pages. The feature automatically converts HTML files with your design and applies them to master pages while creating all the page elements critical for the deployment to operate error-free. Design Manager enables even unexperienced developers to create attractive SharePoint design for both on-premises and cloud solutions.

DON’T Introduce New Web Parts Without Testing the Code

Web parts are the SharePoint-based version of apps. If your enterprise has ever built or deployed an app, you will know that you never do so without first testing it multiple times, in numerous ways, throughout the development cycle.
However, it’s quite common for SharePoint development teams to create new web parts and introduce them to their sites or site collections with little or no testing. It’s also quite common for organizations that do this to suddenly find their entire SharePoint server farm going down, or their online tenant becoming unusable.
It only takes a small coding issue or two in a web part to wreak havoc in the wild. So, to enjoy the benefits of customized web parts without problems, treat them with the same respect as you would a consumer app, and test, test, test before implementation.

DON’T Overdo Document Object Model (DOM) Manipulation

This particular don’t is especially applicable if you are using SharePoint’s modern pages or taking advantage of the platform’s mobile capabilities. Using JavaScript or another programming language to manipulate pages is a favorite SharePoint customization method, because it enables developers to make a wide variety of changes to the environment.
The problem with DOM manipulation, like master page editing, in today’s versions of SharePoint relates to the frequency of updates from Microsoft and the risk that those updates will break the customizations.
Even if your development team's customizations are sound and undergo thorough testing before implementation, the next official SharePoint update could break them in the mobile environment. The only way to guard against that is to test extensively after every Microsoft update, which is often impractical.
Fortunately, it is becoming easier to customize SharePoint without DOM manipulation, so it makes sense to follow the product guidelines and rules and utilize the growing range of tools that Microsoft is providing, such as SharePoint Framework 1.8, which recently became available.

DON’T Try to Outdo Microsoft’s Functionality and Features

The newest iterations of SharePoint are packed full of features available to enterprises with on-premises and cloud solutions. Indeed, the level of the platform’s sophistication is impressive, that’s why your developers, admins, and users might be aware of only a portion of SharePoint’s capabilities.
Given the customization limitations already discussed in this article, it follows that although SharePoint undoubtedly requires customization to suit most business scenarios, adaptation is usually possible without developing functionality from the ground up.

Extend, Enhance, but Don’t Replace

Wherever possible, try to achieve your needs by extending and enhancing the functionality already baked into SharePoint, rather than creating anything new. By staying as close as possible to Microsoft’s core design principles, you can minimize development costs and reduce the risks attached to home-grown features.
After all, nothing your team develops will be tested by as many people as Microsoft dedicates to its products’ integrity. One of the biggest challenges of SharePoint implementations is securing user-acceptance and adoption, and every bug that slips through your QA processes will act against that critical goal.

Trouble-Free SharePoint Customization? DON’T Count t Out

Today, the SharePoint platform remains immensely popular among organizations that need a multipurpose collaboration solution.
For now, customization will be a necessity for many of such organizations. So, if you count your business in that number, the chances of a trouble-free and successful intranet, document management system, or other SharePoint-based business application will increase if you heed the five don’ts outlined by the experts.

Discover and read more posts from Sandra Lupanova
get started
post commentsBe the first to share your opinion
Ana Neto
5 years ago

These are very relevant DON’Ts. I also suffer from the frequency of updates from Microsoft, but in my case it is not customisation projects, but rather integration projects.

For integration projects, for example, integrating Dynamics documents into SharePoint I have found that you are much better off if you can find a solution that guarantees forward compatibility (something like CB Replicator) rather than if you develop from scratch.

When you are developing from scratch it seems Microsoft updates faster than what you develop and your integration project becomes a never-ending story…

Show more replies