Will it work tomorrow? Are your SharePoint Online solutions built correctly?

Over the years Microsoft makes changes that affect a custom built Intranet, help desk, employee self-service or other custom site on Office 365 SharePoint Online. The impact can impact your ability to conduct business.  These changes may impact any web parts, forms, workflows or branding where code was used by the original developers.  Many of these are probably core to the operation of the application solution.   There are a number of other solution development approaches that will become a problem as well.  This article will look at business solution development and the “critical” mistakes internal developers and consultants can make and what you can do about it beforehand. 

As an independent software vendor of “packaged” SharePoint business solutions with over a thousand customers around the world, we at SP Marketplace had to design our products strictly adhering to Microsoft’s solution development guidelines so our customers would not get “burned” by the inherent changes made to Office 365 by Microsoft.  The first rule we have is to keep it “native” SharePoint / Office 365.  Because our products are not “one-off” development, we had to carefully architect the underlying infrastructure on SharePoint Online which will stand the test of time.  From the beginning our products were designed to support the Office 365 multi-tenant environment, rather than retrofitting solutions built on premise, often with coded web parts.  Given this, we thought we would provide input to what you need to look for as critical errors in building applications on Office 365 SharePoint Online.

Critical errors you can make building business solutions on SharePoint Online

Let’s say you want to (or have) build an intranet, or HR portal, or some basic business processes like time-off or a help desk on SharePoint Online.   You will often start with a team site and add function from there.  This is all fine until you find out that basic SharePoint has limited functionality, and its user interface is not the best.  That is when a couple of things start to occur.  First you look for third party web parts or apps to augment functionality, or you start coding.  Many consultants like coding because it gives them ultimate flexibility and runs up the hours.  Unfortunately, as many people are finding, that custom code is what breaks later with the consultant or developer are long gone.   Also, to make SharePoint look better many developers do custom code for branding.  All of this is fine for SharePoint on premise, but a ticking time bomb on SharePoint Online.  Here are the critical mistakes we have seen:

1. Using coded sand-boxed web parts or event receivers – custom built or third party web parts have been the staple of SharePoint Solution development forever.  Often developed by traditional SharePoint Web part vendors, these products were the Office 365 version of their on premise peers.  You will see these offered as tools, and also maybe embedded in some of the fancy out-of-the-box intranet offerings.  Event Receivers are code developed when standard workflows are not enough.  Watch out for all of these!
   
   
2. Fancy Branding – Branding been the revenue generator for consultants for years.  Driven by marketing teams who believe they need the same high investment look and feel of their outwardly facing Internet, in their internal Intranet.  Nice concept, but very costly not only in development cost, but risk of it breaking in Office 365.  To get this fancy branding, developers often change Master pages, or write code.  Microsoft guidelines has said this is a no,no. Beyond the technical concerns, there is the “fit with Office 365” issue.  Microsoft is clearly heading in the direction of a “common user experience” across the Office 365 Ecosystem.  Thus, if your Intranet looks nothing like the rest of Office 365 branding it will stick out like a sore thumb eventually.
   
   
3. Building your business solution as a SharePoint app or add-in – In 2014 Microsoft introduced Apps, a new way to build products for SharePoint.  These are what you see in the app store.  This architecture was designed so each App is isolated with their own user interface, data model and coded processes.  The problem is the isolation.  You cannot share data or cross reference like lists or libraries.  The Apps model is great for tools and utilities, but for actual business solutions like an Intranet or HR Portal, it does not work.  That is why it is now called “Add-ins”rather than applications.  We use apps for specific functions only like custom alerts.
   
   
4. Using non SharePoint native solutions – some out-of-the-box solution vendors are completely replacing the SharePoint front end and only using lists and libraries in the back end.  They have done this because a year ago native SharePoint’s user interface was not responsive (mobile), and clumsy.  Also, it did not integrate well with the rest of Office 365, things like calendars, groups etc.  So these vendors took it upon themselves to provide a better solution.  Unfortunately, that was short sighted, as now Microsoft is integrating Office 365 into a cohesive Ecosystem where native SharePoint no-code business solutions share the new common user experience, integrate seamlessly with the rest of Office 365 services.   With these you may be paying for a lot of coded function that you will get eventually as a part of Office 365.
   ​

​The solution “go native” and buy vs. build

So what can you do.  You may have to rewrite applications or replace them.  First, I recommend  if you can buy vs. build, do it.  ISVs are committed to providing products that will work now and in the future.  We architect and design our products for that.  If you are on a support or subscription plan, we are responsible for our products working on the target platform.  With the recent changes in SharePoint Online, our products worked fine with the latest version.  What many consultants do not realize is the cloud is very different from on premise deployments, in that platform change is a constant and not in your control.  If you build your own solutions, they need to be designed correctly or be ready to update it to support future changes.   Consultants usually do not back their work to support future changes.  Or if they do, it will end up costing you.

At SP Marketplace our out of the box business solutions are SharePoint and Office 365 “native”.  Therefore, we ride on top of most changes.  And they are 100% customizable, so the need to build from scratch is questionable from a business case perspective.  They are up and running within 48 hours and the user adoption rate is high.  Modules include Intranet, department portals, CRM, IT Help Desk, HR and more. 

If you do build your own, make sure you go native. Use Apps or client based web parts.  Make sure you use standard SharePoint or Office 365 capabilities rather than coding anything. 

At SP Marketplace, we have created out-of-the-box "Native" SharePoint templates to transform your Office 365 to a Digital Workplace. Learn more below.
​

Learn More about a Digitial Workplace here

See a Live Demo Here