The PnP Provisioning Engine over the years. A reflection

I dare to say that the majority of developers working withing SharePoint Online have been thinking about automating their provisioning process. At least until a few years until ago.

In the PnP team we noticed that too and many of us in the team had developed their own solutions to tackle the challenge of provisioning artifacts to SharePoint Online. On-premises wasn’t really an issue, as you had the SharePoint Management Shell, but there was nothing to help us in the cloud.

We decided at the time to work on something that we would give away for free as an open source solution, based upon proven templating technology (XML). The requirement we gave ourselves ws that we should be able to easily expand the functionality if future needs change or grow.

We sat down and came up with an architecture that was scalable enough to handle our needs. We needed an XML file, a schema to validate that XML file, and a processing engine. We also wanted our templating concept to be recognizable, so we modelled it a bit after the onet.xml file which was commonly used by people (don’t run away in horror now, please). We wanted the engine to be easily available, so we built it as part of the PnP Sites Core project.

The whole logic in the engine is running around something we call ‘object handlers’. Object handlers are relatively small classes that handle a specific part of the provisioning process. We have handlers for things like content types, lists, site columns, apps, client side pages etc.

Those handlers run in a specific fixed order. And sometimes we run them multiple times during a single provisioning run. Take this scenario:

You want to provision a list, where that list contains lookup fields to other lists. So would normally create those fields first, as you cannot refer to a field if you create a list if that field does not exist. But then as we create a field that needs a lookup to an existing list we have a problem. We need that list to exist first! So what we do is that defer the creation of that lookup field to after we created all the lists and all other fields. Then we go back to those deferred fields and insert them into the lists where they belong. And this is just one example where we had to be creative with the engine. Imagine you having to build all that logic yourself just to provision a field and a list.

We reached our goal to share the knowledge we have about provisioning and SharePoint and managed to wrap it into an engine that easy to use. Actually, the use of the PnP Provisioning engine has exceeded our expectations. It is used on thousands and thousands of tenants world wide on a daily basis and it is being used in commercial products (open source license we use allows that). And the numbers are growing on a daily basis.

For the future? We have exciting ideas that we work on as we speak: Teams, Flow, and more to come!