Hub Sites, Assigned Once — Not After Every Provisioning Run

A hub site is how SharePoint gives a family of sites a shared front door — common navigation, a consistent look, and search that spans every site underneath it. It’s a native SharePoint concept, and it works well, provided every new site actually gets connected to the right hub. In practice, that connection has mostly been a manual step: someone provisions a site from a template, then goes back into SharePoint admin to join it to a hub, one site at a time. Skip that step — or forget it under a provisioning backlog — and the hub drifts out of sync with what’s actually been created. Hub site assignment closes that gap at the template level.

What’s new

A template’s Compliance settings now include a “assign the workspace to a hub site” toggle. Turn it on, pick a hub from the organization’s list of SharePoint hub sites, and every SharePoint site provisioned from that template is associated with the selected hub automatically, during provisioning itself — not as a follow-up task.

• Set once, applies to every run — the hub association lives on the template, not on each individual provisioning request.
• Picks from real hub sites — the dropdown lists the hub sites that already exist in the tenant, so there’s no risk of pointing at a hub that isn’t actually configured as one.
• No manual SharePoint admin step afterward — the site lands already joined to its hub, with the hub’s navigation, branding, and search scope in effect from day one.

Bulk can also join existing sites to a hub, for sites that were provisioned before this setting existed or created outside a template.

How it works

In Template Manage, open the template’s Compliance section and enable “Assign the workspace to a hub site.” A dropdown appears, listing the hub sites available in your SharePoint environment; choose the one this template’s sites should belong to. The setting includes helper text making the behavior explicit: “When enabled, the SharePoint site created from this template is automatically associated with the selected hub site during provisioning.”

From that point on, every SharePoint site — standalone or the site behind a Teams workspace — created from this template is registered under the chosen hub as part of provisioning, alongside the rest of the template’s governance settings: naming, approval, audience, and lifecycle policy.

Why it matters

Hub sites only deliver on shared navigation, consistent branding, and org-wide search if the sites underneath them are actually kept current. When that association depends on someone remembering a manual step after every provisioning run, it’s the kind of thing that reliably falls behind — new project sites, client sites, or department sites that should show up under a hub, but don’t, until someone notices and fixes it by hand. Moving the hub assignment into the template turns it into a rule instead of a task: define which hub a category of work belongs under once, and every site that category produces shows up there automatically, with the rest of your governance already applied.

This matters most at volume. A handful of sites created a few times a year can be joined to a hub by hand without much friction. Once a template is provisioning sites every week — client engagements, project workspaces, department portals — a manual join-to-hub step either becomes a recurring chore for whoever manages the tenant, or it quietly stops happening. Attaching the hub to the template itself removes that choice: the site is governed and discoverable under the right hub from the moment it exists, not from whenever someone gets around to it.

Related

Hub site assignment lives inside the same template flow covered in SharePoint Site Templates Are Now Generally Available. See the platform’s full SharePoint site provisioning capabilities, or book a demo to see it on your own tenant.