How to Enable Saving Templates in SharePoint

In this post: Classic SharePoint Throwback · Why or when do we need a duplicate? · Why isn’t it available in modern SharePoint? · How to make it visible · The real cost of re-enabling it · Locking it back down afterward · Related reading


Classic SharePoint Throwback

Earlier versions of SharePoint — On-Premises 2010, 2013, 2016, the classic versions — let you save a list or site as a template. Having a template makes it easy to clone a list or a site: instead of rebuilding a large list with a lot of columns from scratch every time, you create it once, save it as a template, and reuse that template anywhere.


Why or when do we need to create a duplicate of the list or site collection?

During a SharePoint project, having a clone of the production site is a genuinely safe way to test. It’s more than “another site” — it’s the development site or development list where all the testing and mass workflow runs actually happen. Running messy test items directly inside production lists or sites is a bad idea.


Why isn’t it available in modern SharePoint?

There are 2 reasons it’s not visible: either Publishing Features are enabled on the site, or the site collection doesn’t support custom scripting. In SharePoint Online, saving anything as a template isn’t an option anywhere in site settings by default, because custom scripting is disabled at the site collection level by default.

The Publishing Features case is a separate blocker from custom scripting, worth ruling out first since it’s a smaller, faster fix — disabling the SharePoint Server Publishing Infrastructure feature under Site Settings > Site Collection Features (and SharePoint Server Publishing under Site Features, if it’s enabled at the site level too) restores the option, no PowerShell or custom scripting involved. One real caveat, verified against Microsoft’s own guidance: publishing creates site elements that aren’t supported as part of a template, and disabling the feature afterward doesn’t retroactively remove them — so a site with publishing already used extensively may still not template cleanly even once the feature’s off. Two other gotchas worth knowing before assuming custom scripting is always the culprit: the option is also unavailable by design on Microsoft 365 Group-connected sites and Communication sites, regardless of either setting above.


How to make Saving list / site as template visible

As a global or SharePoint admin in Microsoft 365, you can allow custom script as a way of letting users change the look, feel, and behavior of sites and pages to meet organizational or individual needs. If you allow custom script, every user with “Add and Customize Pages” permission on a site or page can add any script they want. Read Microsoft’s security considerations before enabling it.

Below are the steps to enable templating in SharePoint Online. You need to be a SharePoint admin in your tenant and an admin in your site collection for this PowerShell to run successfully.

Connect to your admin service in PowerShell:

Connect-SPOService -Url "https://yourcompanyhere-admin.sharepoint.com"

Enable custom scripting with the PowerShell snippet below:

Set-SPOsite https://yourcompanyhere.sharepoint.com/sites/Community -DenyAddAndCustomizePages 0

This uses the Set-SPOSite cmdlet from SharePoint Online PowerShell. DenyAddAndCustomizePages is itself a “deny” flag — setting it to 0 (false) turns that denial off, which is what allows custom scripting, and templating along with it. A related object worth knowing is pageContext, commonly used for custom scripting in modern web parts.

You can also use Set-PnPSite from the PnP PowerShell module:

Set-PnPSite https://yourcompanyhere.sharepoint.com/sites/Community -NoScriptSite $false

The real cost of re-enabling it

Worth being direct about something the steps above only gesture at with a link: DenyAddAndCustomizePages isn’t a dedicated “allow templating” switch — it’s the single flag gating custom scripting on the site, full stop. Turning it off to get Save Site as Template back also re-enables the Script Editor and Content Editor web parts and SharePoint Designer’s ability to make script-level changes, for every user with Add and Customize Pages permission, not just the admin running this cmdlet. That’s a real, meaningful expansion of what a compromised or careless account can do on that site — not a side effect specific to templating.

It’s also worth knowing this is no longer Microsoft’s recommended path for the actual goal — cloning a site’s structure — even though it still technically works. Microsoft has moved modern SharePoint site provisioning toward Site Designs and Site Scripts instead: a declarative, JSON-based way to reproduce a site’s structure (lists, columns, content types) that doesn’t require touching the tenant’s custom-scripting posture at all. For a genuinely modern alternative that doesn’t carry the security tradeoff above, that’s the better starting point — worth reading before deciding this post’s approach is the right one for a new project.


Locking it back down afterward

Given the exposure covered above, the responsible move is treating this as a temporary, purposeful change — flip it back once the template’s been saved, rather than leaving custom scripting open indefinitely because it happened to be convenient once. Same cmdlet, flag reversed:

Set-SPOsite https://yourcompanyhere.sharepoint.com/sites/Community -DenyAddAndCustomizePages 1

The template itself isn’t affected by this — Save Site/List as Template produces an actual .stp solution file, stored in the site’s Solution Gallery, independent of whatever the scripting flag happens to be set to afterward. Re-locking the source site doesn’t remove or invalidate a template that was already saved from it; it just closes the scripting surface that was opened to create it in the first place. Worth confirming this on a non-critical site first if it’s not something you’ve done before, rather than assuming it based on this post alone.


DenyAddAndCustomizePages isn’t a dedicated templating switch — it’s the flag gating custom scripting on the whole site. Turning it off re-enables Script Editor, Content Editor, and SharePoint Designer scripting for everyone with Add and Customize Pages permission, not just templating.


Now that’s another tip! Hope it helps somehow. Let me know if you have questions or just leave a comment if we missed something.

Happy SharePointing! #SharingIsCaring

App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning

Leave a Comment

Your email address will not be published. Required fields are marked *