A very common thing I see when working with many businesses implementing collaboration solutions in Office 365, is their rigid desire to implement customisations via code to SharePoint immediately.
Many have a pre-conceived idea of what they believe an ‘intranet’ should be and operate. Thus, they want to force SharePoint to fit that model. The only way to achieve this typically is to use custom code on the site. They want lots of changes made to not only the look and feel but also the functionality prior to implementing it across the business.
I warn them strongly, that the more you customise with code the more it is likely to break and the more issues you will have down the track. A much better option, at least to start with, is to go with what Microsoft provides you out of the box. Only once you have exhausted all in the out of box options, then look at custom code. Then and only then, and when you do be prepared to continually maintain it.
As further evidence for this stance, if you take a look at this video from the recent Microsoft 2018 Ignite from 47:03
and listen to what Tracey Haun, Director, IT Collaboration and Privacy from Dupont says:
When we set up SharePoint we were so proud of ourselves for only customizing less than 5% of the environment and that less than 5% customization has come back to bite us time and time again. Every time we upgrade, every time we migrate we have to deal with these customizations. I just want to say that we were so rigid in the way that we in way we wanted to -- and this is specifically around our records management and the way we classify the security classification of our sites, we were so rigid and so set in our ways on how we wanted to do that. So I highly recommend, if you are just getting started, go with the industry standard. Don’t force your business model into SharePoint. Let the it adapt to the Microsoft way.
Thus, if you want to make major changes to the way SharePoint Online works out of the box you firstly need to find a developer who is specifically experienced with SharePoint Online. Even after the job is complete, you are going to need to have someone on tap to maintain that code, because sooner or later it will break. Why? Because Microsoft makes changes and improvements to the underlying SharePoint base that will affect the code.
When that happens, and you won’t know when it will, the more you have used custom code the more catastrophic the failure of your site is going to be. If the site has become a critical part of your business, then it means that system will be down until a developer can be found to rectify the problems. That could be quite a while.
Putting your business in that situation, to me, is increasing your risk which is not something you want to do. Going with what Microsoft give you out of the box may not be “exactly” what you want but it is going to keep on working as SharePoint is updated, unlike custom code.
Of late, Microsoft has added many improvements to SharePoint and collaboration in Office 365, that really make me question why you would want custom code at all? Is it really worth the risk and costs involved?
So my STRONGEST advice when it comes to SharePoint is to use what you are given out of the box to it’s fullest. After that, if you still want changes, make sure you FULLY understand the indications and increased risk this places your business under.
I’m sure people would love desktop applications like Excel to do more but they generally don’t go making wholesale customisations via code. They tend to work with what they are given out of the box. So too, it should be with SharePoint.