Skip to content

Add support for applying built-in Microsoft site designs (store 1)#5358

Open
fabianhutzli wants to merge 1 commit into
pnp:devfrom
fabianhutzli:feature/builtin-site-design-invoke
Open

Add support for applying built-in Microsoft site designs (store 1)#5358
fabianhutzli wants to merge 1 commit into
pnp:devfrom
fabianhutzli:feature/builtin-site-design-invoke

Conversation

@fabianhutzli

Copy link
Copy Markdown
Contributor

Type

  • Bug Fix
  • New Feature
  • Sample

Summary

Adds support for Microsoft's built-in SharePoint site designs (the "store 1" designs) to two existing cmdlets. Previously, Get-PnPSiteDesign and Invoke-PnPSiteDesign only worked with tenant-registered custom designs via CSOM. Built-in Microsoft site templates such as Event, Department and Human Resources live in a separate store and can only be reached via the SiteScriptUtility REST API with "store": 1 — making them inaccessible from PnP PowerShell without falling back to raw Invoke-PnPSPRestMethod calls.

Modified cmdlets

Get-PnPSiteDesign

  • New -BuiltIn switch (new parameter set). When specified, calls SiteScriptUtility.GetSiteDesigns with store: 1 and returns all built-in Microsoft site designs with their Id, Title and resolved Template enum value.
  • Existing default behaviour (listing and looking up tenant-custom designs) is unchanged.

Invoke-PnPSiteDesign

  • New -Template <BuiltInSiteTemplates> parameter (new parameter set). Resolves the GUID from the existing BuiltInSiteTemplates enum mapping and calls SiteScriptUtility.ApplySiteDesign with store: 1.
  • Existing -Identity parameter set (CSOM path for custom designs) is unchanged.

Implementation notes

  • The BuiltInSiteTemplates enum and its GUID mappings in BuiltInSiteTemplateSettings already existed in the codebase (used by Get/Set-PnPBuiltInSiteTemplateSettings). The new code reuses these mappings directly rather than introducing any new GUIDs.
  • Two utility methods were added to SiteTemplates.cs: GetBuiltInSiteDesigns and ApplyBuiltInSiteDesign. Both POST to the SiteScriptUtility REST endpoint with "store": 1.
  • A BuiltInSiteDesign model class was added to deserialise the REST response from GetSiteDesigns (store 1), which returns Id and Title rather than the full CSOM TenantSiteDesign object.
  • Get-PnPSiteDesign was missing a DefaultParameterSetName, which would have caused an ambiguous parameter set error when called without arguments after the second parameter set was added. Fixed as part of this PR.
  • Documentation included
  • Developed with AI assistance
  • Tested

The existing Get-PnPSiteDesign and Invoke-PnPSiteDesign cmdlets used CSOM
(Tenant.GetSiteDesigns / Tenant.ApplySiteDesign) which only works for
tenant-registered custom designs (store 0). Microsoft's built-in site
designs such as Event, Department and Human Resources live in the SharePoint
site template store (store 1) and require the SiteScriptUtility REST API
with a store parameter — there was no way to reach them from PnP PowerShell.

- Add Get-PnPSiteDesign -BuiltIn switch: calls SiteScriptUtility.GetSiteDesigns
  with store 1 and returns BuiltInSiteDesign objects (Id, Title, Template enum)
- Add Invoke-PnPSiteDesign -Template <BuiltInSiteTemplates>: resolves the GUID
  from the existing BuiltInSiteTemplates enum mapping and calls
  SiteScriptUtility.ApplySiteDesign with store 1
- Add BuiltInSiteDesign model class for deserialising the REST response
- Add GetBuiltInSiteDesigns and ApplyBuiltInSiteDesign utility methods to
  SiteTemplates.cs so the REST logic is centralised
- Fix missing DefaultParameterSetName on Get-PnPSiteDesign to prevent
  ambiguous parameter set error when called without arguments
- Update documentation for both cmdlets with new syntax, parameter descriptions
  and usage examples
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant