← Back to Blog

Explore the SharePoint Add-In Model for Customization and Development

Learn about and explore the SharePoint Add-In Model for Customization and Development

The SharePoint Add-in model gives developers a great deal of flexibility in delivering on customization requirements. By accessing custom server-side code that exists and runs on a remote server endpoint, there is no risk to the SharePoint servers themselves. Some apps include a combination of client and server side code, while others only include client side code. Below is more info about the add-in model and how it can be used by developers.

There are two basic kinds of SharePoint Add-ins — SharePoint-hosted and provider-hosted. To make the best decision about the right kind to develop for your scenario, start by learning what both types of SharePoint Add-ins have in common.

  • A SharePoint Add-in is a self-contained pieces of functionality that extends the capabilities of SharePoint websites to solve a well-defined business problem.
  • Add-ins don't have custom code that runs on the SharePoint servers. Instead, all custom logic moves "up" to the cloud, or "down" to client computers, or "over" to an on-premise server that is outside the SharePoint farm or SharePoint Online subscription. Keeping custom code off SharePoint servers provides reassurance to SharePoint administrators that the add-in can't harm their servers or reduce the performance of their SharePoint Online websites.
  • Business logic in a SharePoint Add-in can access SharePoint data through one of the several client APIs included in SharePoint. Which API you use for your add-in depends on certain other design decisions you make.
  • Almost all major types of SharePoint components can be part of a SharePoint Add-in, including pages, lists, workflows, custom content types, list templates, Web Parts, and more.
  • SharePoint Add-ins can fit into a SharePoint website in several ways: As an immersive full-page experience, as an App-Part, or as UI commands that extend ribbons and menus.
  • All SharePoint Add-ins that users install get a tile on the Site Contents page of the SharePoint website. Clicking the tile runs the add-in.
  • A SharePoint Add-in is configured using an add-in manifest—an XML file that declares the add-in’s basic properties, where it runs, and what SharePoint should do when the add-in starts. Among other things, the manifest can specify what languages the add-in supports, what SharePoint services and functionality it depends on, and the permissions to the host web that the add-in needs. (SharePoint Add-ins have full control of their own add-in web.)
  • You distribute SharePoint Add-ins in add-in packages that always include at least the add-in manifest. (If there are no SharePoint components, the add-in manifest may be the only thing in the add-in package. ) If the add-in has SharePoint components in an add-in web, these are included in the package as a set of XML files. Remote components that are hosted outside of SharePoint, such as a remote web application or database, are not included in the package and are deployed separately from the add-in package. (However, the add-in manifest does specify the URLs of the remote components.)
  • Add-in packages can also include Office Add-ins. When the SharePoint Add-in is installed, the Office Add-in is added to an Office Add-ins catalog in SharePoint. Users can install it from the catalog into the Office applications like Word or Excel.

A couple of points for veteran SharePoint developers

Microsoft has deprecated sandboxed solutions that contain custom server-side code, but still support "No code" sandboxed solutions and sandboxed solutions that contain only JavaScript.
SharePoint Add-ins don't use the server-side SharePoint object model. The client-side object models are greatly expanded in SharePoint 2013. Although some APIs in the SharePoint server object model aren't available in the client object models, these are almost entirely administrative and security-related classes. Custom SharePoint logic that addresses these areas is more appropriate for a Windows PowerShell script or classic SharePoint farm solution.