Ever spent an entire afternoon manually tweaking a new SharePoint site—only for the next one to look completely different? There’s a smarter way to guarantee every site matches your vision, without losing hours to repetitive setup.Today, I’ll show you the exact steps to automate branding, lists, and permissions using Site Scripts and PnP. Why keep repeating yourself when you can build it once and scale instantly? Stick around to see how you can finally make SharePoint play by your rules.Why Manual SharePoint Sites Always Drift—and How Site Scripts Get You Back on TrackIf you’ve ever sat down to create a SharePoint site with high hopes, only to revisit it a few days later and wonder what happened, you’re not alone. You map out the perfect site layout—maybe sketch some ideas for a consistent logo, pick just the right shade of blue for the header, list out all the custom permissions your department needs. But then it’s time to build another site. Suddenly, you’re flipping through your notes, pasting snippets from a Word doc last updated before Teams even existed. What started as an organized process starts to feel more like remembering all the right spices when you’ve left the recipe at home. Things drift. Someone sets the wrong banner color just once, and now it’s quietly become the default. Or maybe someone forgot to recreate a specific list, and now there’s confusion about where files are supposed to go.It’s the sort of chaos that sneaks up slowly. Even when you try to stay consistent with templates or checklists, little inconsistencies creep in. You’ll notice the first site is using the corporate font, but the next one mysteriously reverts to Arial. One site has a document library laid out with sorted columns, but somewhere along the line, the sorting gets lost. And permissions—a favorite source of headaches—always seem to get muddled. Maybe in a rush, someone forgets to break inheritance on a confidential folder, and now everyone in the company stumbles into files meant for the Finance team only. Templates help, but they’re only as reliable as the person executing each step. The more sites you spin up, the harder it is to guarantee they look and work the same way every time.Let’s give this a real-world spin. Imagine you’re launching a new department site on Monday. You’re careful with the branding, spend extra time adding a custom list for asset tracking, and you even double check the permissions. Fast forward to Friday—a new site is live for another team. You pop in to review it, and instantly see problems. Fonts are off. The logo is the wrong size. The custom asset list is missing. Permissions are inherited straight from the parent, opening up sensitive data to everyone. Two sites, less than a week apart, but you’d never guess they came from the same setup process. It’s not a lack of effort; it’s just inevitable drift. The more manual effort and memory involved, the less likely two sites ever wind up matching.So, Site Scripts show up promising to fix this. But there’s this nagging question: is a long string of JSON commands actually going to make things easier, or is it just another layer you’ll end up managing? Here’s what Site Scripts actually bring to the table—the magic is in the instructions. You write out, in plain text (JSON), exactly what you want SharePoint to do. “Apply this color theme. Upload this logo. Create this list.” Each step, spelled out in a way SharePoint understands, so you’re not relying on memory or someone’s best guess. It’s like finally getting your hands on a recipe card that actually lists the right measurements.Branding gets locked in by default. You upload a logo once; every new site is stamped with it. Headers and navigation keep the same look—whether you’re spinning up a single-team site or launching ten department hubs. The days of “wait, did I forget to update the header again?” are over. And it doesn’t just stop at coloring. You can bake in structure, specify which lists to build, and customize the user experience at the moment the site is created.Seeing is believing. Picture the difference: one site manually built, with tweaks from memory; the other using a Site Script, where every color, logo, and list appears exactly as planned, every single time. It’s not a subtle improvement. Even a quick glance shows you which approach is running on autopilot, and which one is clinging to manual fixes. And here’s the surprise—there’s no programming degree required. Site Scripts are for admins who’d rather be efficient than deeply technical, letting you enforce standards without learning to code.But, of course, branding is just the front door. What about everything inside—lists, libraries, the actual content that makes a SharePoint site useful? That next step takes you from pretty sites to ones that really get work done, and that’s where the real taste of automation begins.Building Your First JSON Site Script: Branding, Lists, and a Taste of AutomationSo now you’ve seen what Site Scripts promise, but let’s talk about what actually happens when you try to build one yourself. Imagine sitting down at your workstation with a blank JSON file open in Notepad. No templates. Just an empty screen, blinking at you, daring you to make the first move. Most of us start by staring at the documentation, maybe even copy-pasting, only to realize this thing has its own logic. Miss one bracket or put a comma in the wrong spot and you’re rewarded with an error that reads like someone mashed the keyboard. For most admins, the experience feels uncannily like trying to follow a recipe written in shorthand: it’s technically there, but the smallest misstep throws the whole thing off.Let’s break through the fog with a real example—a minimal Site Script that applies a company theme and adds a simple list. Even in its simplest form, what’s in this file governs how your SharePoint site looks and functions the moment it’s created. You’ll see keys like “verb,” which tells SharePoint what action to perform, “applyTheme” for branding, and “createSPList” for new lists. If you’re thinking this all feels a bit like building IKEA furniture—for SharePoint—then you’re not far off. Everything has to happen in a certain order, and the labels might be confusing at first, but the end result is solid if you follow the instructions step by step.Pretend for a minute you want all your project sites to launch with company colors—no random purples or retro gradients—and a tracker list for action items. Your JSON might start with an “actions” collection, basically the heart of your script. The first action: { "verb": "applyTheme", "themeName": "Contoso Blue" }This line means SharePoint will snapshot your default look and apply it to every site using this script. No more nightmares where one department has a teal banner while everyone else is navy. Then comes the structure part:{ "verb": "createSPList", "listName": "Action Tracker", "templateType": 100, "subactions": [ { "verb": "setTitle", "title": "Action Items" } ]}Here, it calls for a fresh SharePoint list named “Action Tracker,” built on the generic custom list type. Under “subactions,” you can fine-tune details—maybe set the default view or add columns—but let’s keep it simple for now. Think of it like making lasagna: if you skip the noodles, it falls apart. If you add the wrong list template, you won’t get what you’re expecting. Each action, down to the order, needs to be right for things to come out as planned.Once your script is saved, SharePoint doesn’t magically know it exists. You need to register your Site Script and then associate it with a Site Design—a reusable package that users can pick when creating a new site. Inside the SharePoint admin center, you go to the Site Scripts section, upload your JSON, and give it a name you won’t forget later. Then, create a Site Design and point it to your script. When users choose this design, SharePoint runs your instructions the moment a new site spins up. You don’t have to hover over them or check settings the next day.Watching this in action feels, frankly, pretty refreshing after years of manual site tinkering. The site pops up with the company’s branding perfectly in place, your “Action Tracker” list right there on the homepage, and not a single errant color or missing list. If another department needs the same template tomorrow, you can give them a site that matches—without ever redoing the work or trusting that someone remembers how you “did it last time.” That’s the biggest win here: the reduction in friction and the confidence that every site starts on the right foot.For most admins, this covers almost everything they ever wish would “just work” during site creation. No more missed lists, off-brand banners, or forgotten manual steps. Even this basic setup solves the majority of headaches you’ll find in day-to-day SharePoint management. But as much as this automates, there are still gaps. Not everything can be set in stone with JSON. So, what if you want to automate deeper—like tweaking permissions or dropping in custom web parts, or handling those settings that just don’t appear in the JSON reference? That’s where things start to get interesting.Where Site Scripts Stop—and PnP PowerShell Picks Up the SlackIf you’ve ever tried to push SharePoint automation beyond just branding and simple lists, then you’ve probably run into the infamous Site Script limitations. You get your JSON script working like clockwork—color palette locked down, that must-have Action Tracker list in place—but you quickly notice the fine print in the documentation. Need to grant unique permissions to a document library? Want to roll out a custom web part tied to your departmental workflow? Site Scripts just give you a polite shrug. There it is in the support matrix: “not supported.” Suddenly, the automation that promised freedom now has you scrambling for manual fixes again.And let’s be honest, the whole point of automation is to avoid those manual

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.