The mystery of isprovisioningComplete
Table of Contents
If you’ve ever been provisioning SharePoint sites you might’ve wondered why when using SDKs like PnP.Framework or PnP Core creating a site seemingly takes ~45 seconds, but why is that? - when the user presses the create site button in the SharePoint UI it’s done in a few seconds.
The SPSiteManager API
My initial thought was that the SharePoint UI was doing something special, so I did a bit of digging, and what I found was that to my surprise the SharePoint UI uses the SPSiteManager API - alright, that’s a publicly documented API, so I should be able to use that too, right? - this should be a quick PR to the PnP SDKs and boost that performance for everyone 🎉
The mystery of isprovisioningComplete
Well then looking at the PnP.Framework source code, it’s already using the SPSiteManager API, welp then, why is it then slow? 🤔
After a bit more digging (okay, maybe more like scrolling a few more lines and reading the code) - I found that the SDKs are repeatedly querying the sites web object, and checking the status of isprovisioningComplete
, a boolean value, but what is it? - what does it do?
Well, I’ve seen it in the past, but never really cared, cause it wasn’t in my way, but now it is, doing a quick google search (I even tried Bing) basically gave me nothing, so I had to dig deeper.
What now?
Well as I didn’t really get any good results from my search, I got desperate, and took to X, where the lovely Vesa came to the rescue with some real insight, and not just guessing, like what I had been doing up until now.
Well then, as it turns out, there might be a very good reason for you to wait for the site to be done creating, as things might not work as expected if you don’t.
But in my particular case, I was planning to do a combination of creating a site with a site design, and then use PnP Provisioning to create a few site pages, as the Graph site pages API still was a bit new for this solution.
So I managed to take my provisioning time from 48 seconds to create a site, and then 15-20 seconds to apply the template to a total of 25 seconds.
Doing it with PnP.Framework
This was how I was creating my site before:
// 48386ms
var site = await new SiteCollection(web).AddAsync(new SiteCollectionCreationInformation
{
Title = "My new site",
Url = "mynewsite",
Description = "My new site",
Lcid = 1033,
Template = "STS#3",
Owner = "owner@tenant.com"
});
What I found just reading through the source code was that the awesome folk who built the SDKs had already thought about this, and added a noWait
parameter to the Create
method, so I could just do this:
// 2341ms
var site = await new SiteCollection(web).AddAsync(new SiteCollectionCreationInformation
{
Title = "My new site",
Url = "mynewsite",
Description = "My new site",
Lcid = 1033,
Template = "STS#3",
Owner = "owner@tenant.com"
}, noWait: true);
What a difference, but of course, beware that this doesn’t mean you’ve just shortened your provisioning time to nearly nothing - cause you might still have some issues adding content types, or other things, but from my experience adding site pages didn’t cause an issue, so what I ended up doing was extracting the WaitForProvisioningIsComplete
method, and called that in my own code after I had added the pages, but before I started working with content types.
TL;DR
If you’re using PnP.Framework or PnP Core to create SharePoint sites, and you’re wondering why it’s slow, it’s because it’s waiting for the site to be done creating, to give you the best experience, you can speed it up by skipping that step using the noWait
parameter, but beware that you might still have to wait for some things to be done, to not have funky behavior so be careful.
In conclusion: The isprovisioningComplete
is actually named pretty intuitively, it tells you if the site is done provisioning, who would’ve thought? 🤷♂️