Settings Field Reference

This is the field-level companion to the Settings map. If you know which screen you want, Settings Home and Map gets you there. If you know which field you want, or you need to know who is allowed to change it, you are on the right page.

Two columns are the reason this page exists: Minimum role, which no owning page carries, and Publish required?, which answers the most common follow-up question about any settings change.

How to read the tables

Three conventions, stated once and not repeated per table.

Minimum role is the weakest of Leed’s six roles that satisfies the privilege the screen enforces. Anyone stronger can also do it, and a resource-level override can raise one person’s effective role on one resource without changing their base role. The ladder, strongest first, is Administrator, Content Publisher, Content Approver, Content Writer, Read Only, Restricted.

Publish required? means the change is saved in the CMS the moment you make it and reaches your published site only through a deployment — which is nearly everything on these screens. It describes the deployment, not a permission: there is no separate “publish” privilege per settings screen to go looking for.

A screen you cannot see at all is a read-privilege decision made before the page renders. The Settings landing grid is assembled from the cards your role may read, which is why two administrators and one writer genuinely see grids of different sizes.

Settings → General

General is a single sub-route, /settings/site, rendered as five stacked sections in this order: General Details, Socials, Documentation, MCP Configuration and Default Configuration. General Site Settings documents the screen; the tables below carry only its permissions.

Every field in every section is read with company:read and written with company:write, without exception. That uniformity is the whole reason these tables are short.

Domain and Preview Domain are not editable at all, which is why their Minimum role is n/a rather than a role name. General Site Settings explains why, and covers the Domain Connect button’s disabled tooltip, which names the wrong role.

The CMS surfaces four social handles; the underlying company record models more than four, and one key does not match the name a template author would guess. Both facts belong to General Site Settings, which carries the full list.

Naming a custom theme, font or code theme is a Starter feature, and the gate fires only when the value actually changes — reopening Settings, clearing the field, or swapping one built-in for another passes on every plan. A malformed name is rejected with a 400 before the tier is consulted, on every plan including Enterprise; the exact message is on Common Error Messages. The theme name is set here; the CSS that makes a custom name mean anything is written in your repository — Custom Documentation Themes.

This section renders only when the workspace’s MCP entitlement is true, which is the default on every plan. If you cannot find it, that flag is unset on your workspace rather than your plan being too low — MCP itself is free on every tier.

Settings → Team Members

The content-model screens

Four screens, two of which have no editable fields at all.

The capture and automation screens

Settings → Plans & Billing

The one screen whose read gate is a write privilege. It is guarded by billing:write plus the billing resource override, so the minimum role is Administrator — or anyone with the Billing checkbox ticked on Settings → Team Members.

Privilege to minimum role

Every role name in the tables above is derived from one of these twenty-one privileges. This is an extract; the complete matrix and the full role model are owned by Privilege Matrix, read from the role’s point of view at Who Can See What.

Fields that are not in Settings

Several settings-shaped things live elsewhere, so a reader who searched this page and found nothing can stop searching.