A meaningful collection of Lego bricks is a toy. A meaningful collection of Lists, Fields, Files and other SharePoint artefacts becomes a SharePoint Application. Private picture.
App, Add-In, List, Web, Site, Sandbox solution, Workflow. There are too many words flying around in SharePoint that confuse users and Non-SharePoint-Developers. I want to introduce a “new” concept that is so simple and that a company can understand and govern: a SharePoint Application.
That is so simple. It can be called a tool, a functionality. That can be a SharePoint list, a document library with a workflow, or a document library with custom jslink. All they can be SharePoint Applications. Let’s use lego as a metaphor. Have you seen this?
The same toy car in just brics. SharePoint Artefacts like Webs, Lists, Fields, Content Types, JSLink etc are just lego bricks. Private picture.
These lego bricks together become a cool toy that you can play with (as you can see in the picture above). So it is with SharePoint Applications, too. SharePoint Applications solve actual business needs. A List, or a JSLink by themselves do not solve a business need. It must be a meaningful collection of SharePoint Artefacts that becomes a SharePoint Application.
Does the lego metaphor make sense to you? To go back to SharePoint, I’ll give you an example of a SharePoint Application. I would say everybody has done such Applications. In a project we created a document library for product icons that were used for all products in a company. Easy? Yes. But the icons had several states (active, inactive…). Versioning and Approval was required. A workflow for new requests and submits was implemented, too, permissions for different roles, metadata navigation in the document library and so on. Sure, SharePoint provided us with great “lego bricks”. But we created a tool, a functionality – a SharePoint Application, that makes sense to our business.
What’s new then? Well, we all have done such applications. The new is to understand SharePoint Applications as an own alternative and quality assurance. See more below.
Another example is an “App” for SharePoint Online that I converted into a SharePoint Application by adjusting it for SPO and OnPrem. That’s when I came up with the idea of the SharePoint Application.
A SharePoint Application is a meaningful collection of SharePoint Artefacts, like Webs, Lists, Fields, Views etc that becomes an entity and solves a business need. SharePoint Applications follow best practices and quality policies as all other applications.
To understand more, let’s compare with the related concepts:
SharePoint Application vs SPList
An SPList (an “app”) is often only a part of an entity. Users often create two or more lists, update views and so on. A SharePoint Application contains a list and everything else ready for satisfying business needs.
SharePoint Application vs. SharePoint Hosted App (Add-In)
An SP Hosted App resides in a different domain, it is a subsite that is only trusted to do some predefined actions. An SP Hosted App allows separation of trust, it can be uninstalled easily and it is always a separate site (Web). A SharePoint Application is more flexible (it might be a list in the same site). It is closer to the actual site where users need this functionality. A SharePoint Application is in the same domain name and has the full user trust. A SharePoint Application does not require App Infrastructure and separate domains. It is searchable and can benefit from BlobCache (Style Library) to ensure good web performance.
SharePoint Application vs. Provider Hosted App (Add-In)
SharePoint Application uses SharePoint Templates, Information Architecture, Search, Identity Management etc. A Provider Hosted App is a dedicated web application outside SharePoint. A Provider Hosted Application is powerful because it is not bound to SharePoint. All advantages and disadvantages are the same as the ones for a custom ASP.NET application. A Provider Hosted App has a connection to SharePoint, it requires a Trust and App Infrastructure in your environment. A SharePoint Application is not that powerful, but as long your business need can be solved by SharePoint lists, Page Layouts, Workflows, then a SharePoint Application is the right choice for you.
Quality and Governance
To ensure quality, every SharePoint application should comply with policies and fit into the overall Govenance model. Treat them as they were other Applications. They must have system documentation, application lifecycle management including versions, upgrades and rollbacks. They must be staged and tested before going to production. Another example of a quality policy is that a SharePoint Application is provisioned, maintained and operated using only Client Side Object Model – no farm solutions. All SharePoint Applications are tracked in a system for a better supportability.
Provisioning Framework for SharePoint Applications
I would strongly recommend using a framework for provisioning your SharePoint applications. My favourite is SPMeta2. There is also PnP which is a strong community. It might be okay with manual setups (click-click in SP) for smaller applications. My advice, though: Require code based, repeatable, code-documented and tested provisioning of SharePoint Applications even for smaller ones.
SharePoint Applications have been around for a long time. My goal is to give them a name so we don’t need to be confused by apps, add-ins, lists. A SharePoint Application is not a technical term, it is just a meaningful solution for a business need, done in SharePoint that leverages high quality by following policies and standards within a company.