There are many different scenarios in which you might want to be provisioning a large number of SharePoint sites at once, or to set up a uniform way for sites to be set up. Using SharePoint for projects is a prime example of how organizations need to set a standard for the setup of a SharePoint site. Doing this manually can be a tiresome chore, and a waste of time and resources that could be put to better use elsewhere.
In older versions of SharePoint, this was addressed using Site Templates, so that when a user created a new subsite, they could select the template and provision a site according to the standard requirements.
In the Modern SharePoint, using Site Templates is problematic, particularly because the recommended site hierarchy is flat, using Hub Sites, instead of the traditional monolithic structure of subsites. Because of this, Site Designs present a solution for a standardized approach to the creation of Sites.
A couple of concepts, before we begin:
Site Scripts
These are a collection of actions, in JSON format, that dictate what needs to happen. These are executed in a linear fashion, with each action in the script executing in order.
Site Designs
These are the containers for Site Scripts. Each Site Design can contain multiple Site Scripts, and a Site Script can belong to multiple Site Designs.
Initial Considerations
There are some limitations to Site Scripts, at the time of this article’s creation:
- Managed Metadata is still technically unsupported as a column type. There are workarounds, but they require a fair amount of trial and error, and may not be successful in the end.
- There is a limit of 300 actions in a script. This may seem like a lot, but since the script executes sequentially, a fair amount of consideration needs to be undertaken to make sure that each action is able to be executed. For example, trying to set a navigation link to a list that hasn’t been created yet will fail.
- If you are leveraging content types, you can only reference those created by the script, organizational content types are not supported.
- Pages cannot be created or manipulated, so page layouts and web part placement/configuration are not possible to be manipulated.
Site Designs (which contain Site Scripts) can be applied through the menu, or set in the Hub Site Settings as the default for all sites associated to a Hub. For example, you can create a Projects Hub site, and set the default Site Design to be applied to all Site Collections associated to the hub to be your Project Site Design. In this way, users can create a new Project Site, and have lists, libraries, and navigation automatically configured for them. This can extend through adding users to the site, or even enabling external sharing.
Site Scripts and Designs can be deployed and updated using Powershell. Reference for how to deploy and update Site Designs and Scripts can be found here.
Below is a sample Site Script we use to provision Project Sites. It should be noted that this is one of several scripts used, this has been provided as an example.
For a full Site Script Schema Reference, see this page on Microsoft Docs. This sample adds me as an Owner of the site, triggers a Flow that does a number of actions required for setup, and then begins creating a number of lists/libraries required for Bloom Software’s project management processes.
This sample should give you everything you need to get started. The beauty of Site Designs is that you can set them up to meet your specific needs, and enable your end users to easily trigger them to deploy sites quickly. At Bloom Software, we also use a specific set of scripts to allow for a set of lists to be created and deployed in any site, allowing us to easily add functionality to a previously created site.
While Site Scripts and Site Designs have some limitations that make them less than ideal for a robust deployment scenario, planned properly they can provide a lot of benefit when it comes to frequent deployment tasks.
