Easy Settings
The settings people actually ask how to change
One search box over every SharePoint setting we can write, with the ones people ask about most at the top. Search by the setting's name, by the API property, or by the problem you are actually having - "cannot sync", "checked out", "script editor web part missing" all find the setting behind them. Many of these have no page in the SharePoint admin centre at all: without this you would be writing PowerShell.
What it does
- What a setting is set to right now, in plain English rather than an API value.
- Which settings have no admin centre page, marked with a PS only badge.
- Which need the SharePoint Administrator role, and which a site owner can change alone.
- What a change will break, before you make it.
- The PowerShell that does the same thing, on every setting, ready to copy.
How it runs
- Sign in. One tenant, asked when you click the tile. Any of the three credentials works here.
- Choose a site and a list. Tenant settings need neither; site and list settings say so until you pick one.
- Search, or browse by scope. The rail narrows the list to tenant, site, or list settings. It is a filter, not a different page.
- Press Change. The dialog shows what it does, what it breaks, and what it is set to now.
- Apply. Apply stays greyed until you actually change something. One setting, one write.
How it works
Values are read in groups when the page opens or you press Refresh: one read fetches every setting SharePoint stores together. A group that cannot be read, such as the tenant settings without the SharePoint Administrator role, marks only its own rows, with the reason. Choosing a different list reads only the list settings again.
A change is one setting and one write; nothing is batched, so a failure never leaves an unknown mix of settings applied. Because SharePoint stores settings in groups, the setting's group is read again immediately before the write and sent back with only your one value changed, so a change someone made elsewhere in the meantime is not put back.
After the write the value is read back, and the row shows what SharePoint actually holds. SharePoint sometimes accepts a change without an error and keeps the old value, for example a site sharing level above the tenant's, or some list settings on a document library. When that happens the dialog stays open and reports the change as not applied, naming the value you asked for and the value SharePoint kept.
ShareMaster keeps no history or backup of these changes. To reverse one, open the setting again: the dialog marks the current value and you choose the earlier one. A setting that cannot be written is never sent; its row shows the PowerShell to run instead.
What you need
- Site owner or better for the site and list settings. No tenant role and no admin consent for those: they run on SharePoint's own APIs, so a browser sign-in is a complete credential.
- The SharePoint Administrator role for the tenant settings. Without it the Tenant section still lists them, greyed, with the reason - it does not pretend they are not there.
- A few settings need an extra licence, such as SharePoint Advanced Management or Copilot. Those carry a Licence badge.
What it will not do
- One site and one list at a time. It is a settings editor, not a tenant-wide sweep.
- Some settings Microsoft documents cannot be written through any API we can reach. Those are shown read-only with the PowerShell to run instead, rather than hidden.
- Custom script is put back to Blocked by SharePoint within 24 hours, whatever you set it to. That is SharePoint's behaviour, not ours, and the dialog says so.
- Lowering a version limit deletes the versions above it permanently. They do not go to the recycle bin.