SharePoint sites that build themselves
Add a client to a list and the whole SharePoint structure appears, client hub to project sites, already connected.
- For
- A services business
- My part
- Architect and developer
- Status
- Completed
The problem
Every new client needed the same SharePoint setup: a place for the client, a place for each of their locations, and a site for every project. Doing that by hand is slow, and worse, it drifts. Names stop matching, a hub association gets missed, and six months later nobody can find anything.
How it works, in 5 parts
Add a client
A new row in the Clients list is the only manual step.
Build the client hub
A flow creates the client's hub site with the right template and naming.
Add each location
Every location gets its own hub, associated with the client's hub.
Create project sites
Project sites are created and joined to the right location hub.
Connect everything
IDs, URLs and relationships are written back, so every site stays linked and findable.
What I built
A provisioning system with a simple rule: the Clients list is the source of truth. Adding a client triggers the build, a client hub, then location hubs, then project sites, each created from a template and associated with its parent. The flow writes the new IDs and URLs back to the list, so the structure documents itself.
The shape is three levels deep: Client hub → Location hub → Project site.
The hard parts
SharePoint takes its time. A site isn’t always ready the moment the API says it was created, and hub associations can fail if you’re too quick. The flows wait, check and retry instead of assuming.
Identifiers everywhere. Every level depends on IDs from the level above. Getting those dynamic identifiers and URL structures right is what keeps the hierarchy from quietly falling apart.
What I learned
This was architecture more than automation. The flows are the easy part; deciding the structure, the naming and the single source of truth is what makes it hold up a year later.