I have been recently exploring creating sites with Flow off the back of a list. I'd done this previously with Azure Functions very successfully but wanted to see if Site Scripts and Site Designs could remove that extra step. TLDR? Yes you can!
There are some great posts on creating Site Scripts and Site Designs (see additional links at the bottom of the page) but the basic one on Microsoft Docs gets things going pretty quickly.
So how does Flow create the site? Creation of a Team Site using REST does not appear to be that well documented and I couldn't find any examples of creating a site with a site design in one step. This was a little odd so I took a look at what calls the main SharePoint page uses to create a site and the key appeared to be:
Massive caveat here - as these APIs appear to be minimally documented, they may be subject to change at short notice.
There are a few examples of using this out there (try Googling CreateGroupEx) that allowed you to pass the DisplayName, the Alias, whether it is public and even some that covered classification. However, I couldn't find any that passed anything to set the Site Design ID. Thankfully, Chrome came to the rescue and I found that it was passing the JSON below.
A little bit of time later (and some swearing too...) I realised that the later half of the implicit_formula section was in fact the Guid of the Site Design. Once I had this I was away and running.
![Returning-Site-Design-List](/images/2018/07/Returning Site Design List.PNG)
I created a Flow that triggered from a SharePoint list containing the list of projects. It first retrieved the list of Site Designs to get the Guid - I could have hardcoded this but wanted to allow it to be more user friendly and retrieved by name, matching what the user would do. It then iterates through the designs until it found the matching one and made the call to CreateGroupEx.
![Create-Project-Site](018/07/Create Project Site.PNG)
The REST API calls were made using the relatively recent SharePoint activity called "Send an HTTP request to SharePoint" which meant that there was no need to work with any tokens or credentials.
There are still many cases where you would need some additional scripting that would require the PnP provisioning templates for more advanced scenarios and so would use an Azure Function but for situations where you don't want to have to have an Azure subscription (it can take months for some enterprises to agree that this is something that should be set up) then this is a good alternative. Chris O'Brien covers some great scenarios in his SharePoint Nuts and Bolts post below.
Happy site creating (but don't forget the governance...)!
p.s. Yes, I know I've been quiet on here. Sorry. Life, work, kittens. All got in the way.