Having several different SharePoint Online projects completed over the last couple of … years really; several bigger ones still ongoing, I thought I would share few things with you that might help you from a technical perspective to avoid things that can’t be done.
In no particular order – here they come:
1. SharePoint Apps are not your typical web parts, there are limitations related to functionality and branding
Ok, so you still have web parts in SharePoint Online but everyone out there says “no more web parts, build only apps”. So you might think, well apps are new web parts. Not quite.
Some of the limitations of SharePoint hosted apps include:
-Only client code is supported in apps
-Where you need it or not – each app gets an app site
-Each app needs to request set of permissions which users just allow otherwise you app won’t work
-Apps parts in apps run on host sites as iframes – so you can’t access or manipulate DOM of a parent
2. Be careful with promised custom functionality in your workflows, you are limited to out of the box workflow actions
SharePoint Online allows you to build workflows in SharePoint Designer – this is old news. However, you can also build workflows in Visual Studio and deploy it to SharePoint Online; just use the Visual Studio 2013 workflow template. The limitations of such workflows are to actions already deployed within SharePoint Online. In other words, you can’t run your own custom actions. Having said that, out of the box actions are quite extensible and there is a lot you can achieve.
Be careful when promising your customers that you can run out of the box workflow on the app site – limitations on that site break workflow initiation even for out of the box workflows
3. Sites created by apps (aka app sites) are limited in functionality, for example tools such as SharePoint Designer and many 3rd party migration tools are not able to connect to them.
Despite the fact that apps sites should be just sites – they have a limited functionality so make sure you test your typical assumptions and test scenarios since some of them may fail. Here are few examples:
-Connecting to an app with SharePoint Designer Fails
-Many third party migration tools are not able to connect to the app site to deploy or read data
-Limited workflow initiation functionality for out of the box workflows
4. Deployment of site artifacts (master pages, layouts, images) should be done with Sandbox Solution; using apps makes it clunky.
Even though there is a theoretical option to deploy your branding and other site artifacts (master pages, content type etc) to a host/parent site using app framework – due to lack of proper support in apps to deploy those artifacts, practical implementation is beyond reasonable.
5. Have old PowerShell to deploy and configure your solutions to SP On Premise? reusing it for SPO will require tweaking
Many of us use automation to deploy site artifacts, solutions etc; I have quite a few PowerShell script that do a lot of magic in SharePoint on-premises. Don’t assume those will work seamlessly in SharePoint Online. Test them, there is a very high chance you may need to do some tweaking. In some cases, functionality is not going to be supported. The reason being, is that SharePoint Online supports Remote PowerShell which has a limited subset of functionality.
6. Be careful with customizing SPO core elements: Suite Bar, navigation, etc – things tend to break when MS pushes out an update
Suite Bar, showing on the very top of any SharePoint Online site is by far the most dangerous place to put your customization into. Many customers will ask you to add their custom links, remove out of the box links and many other requests. Most of such customizations may work at first, but there is a very high risk of this functionality breaking when Microsoft updates UI and Suite Bar is their favorite place from my experience.
I have had several instances when Suite Bar HTML rendering was changed resulting in anything that relies on it break and cause multiple errors on the page. Microsoft doesn’t provide any release schedule on such elements so you might get a nasty surprise one evening. Therefore, best is to stay away from customizing core elements such as ribbon and suite bar in SharePoint Online.
7. Your SPO tenant shares some services with others – remember that when creating solution that use search, user profile, translation etc
There are many clever solutions out there which use Managed Metadata, User Profile and Search Service. Remember that those services run in multitenant environment and latency of those is significant comparing to on-premises system.
To give you some examples:
-Search crawl can take several hours for the new search properties to be picked up
-User profiles take a while to be created manually; even the user profile property page takes few minutes to load up
-Multilingual capability in SharePoint Online which uses timer job can take up to an hour to create a translation package depending on the volume of pages
8. Avoid big bets on solutions that are not officially supported since you never know when those will be officially discontinued (example is BCS support for Kiosk users)
SharePoint Online is evolving and licensing is evolving with it. Depending on how you put together your solution – you may want to sell your customer certain level of licensing (say kiosk user license) based on availability of certain features (such as BCS) when tested the product. Although some features are available, licensing clause may explicitly or implicitly say otherwise. Avoid solutions which are built on limited availability of some features, especially if there are strong indications those features should not be there. You never want to have a core feature to disappear one day because technical hole has been patched and now you have hundreds of thousands of disappointed users.
9. Remember, the storage is now in the cloud: test migration of large volumes of data – you might need to migrate weeks worth of data without realizing it initially
This lessons learnt speaks for itself – when migrating – don’t assume this is going to be fast. Even the most ingenious migration tools out there can’t do much when it comes to transferring data across internet. Test your migration and establish baseline.
There are of course may more lessons and depending on the type of the solution you’re building – you might find several more. Above are the most common when building typical intranet or extranet solution and I hope it will save time during planning and execution of your next SharePoint Online project.