Settings Home and the Settings Map

Settings opens from the gear in the bottom utility cluster of the rail — below Send feedback, above your avatar — or directly at /settings. What you get is a searchable grid of cards, one per configurable surface, and this page is its index. Almost every card leads somewhere another part of these docs already documents end to end, so the job here is to hand you the map: which card, which route, which page explains it. The Settings screen itself is available on every plan; exactly one screen behind it — the one the Dynamic CTAs and Recommendations cards share — is gated by your subscription as a whole, and one more card, CI trust, gates only the form that registers something new.

The card grid

The screen opens with a Setup eyebrow, the heading Site settings, and one line of intent: “Configure how your site behaves, who has access, and how content moves. One-and-done setup lives here so the rest of the CMS can stay focused on the work.”

Below it the cards are grouped, always in this order: Workspace, Content model, Capture & engagement, Automation & AI. Cards render two to a row on a wide window and one to a row on a narrow one. Each card is a link — icon tile, title, an optional pill, a one-line description, and a chevron.

Nearly every card names an object that Leed defines once and reuses everywhere — page type, label, menu, journey stage, path — and core concepts is where those definitions live.

Searching settings

The search field sits above the groups and is always visible. Its placeholder reads Search settings — try ‘labels’, ‘journey’, ‘automation’…, and the key cap beside it shows ⌘K.

Press Cmd + K (or Ctrl + K) anywhere on this screen and the field takes focus. The filter is a case-insensitive substring match over three things at once: the card’s title, its description, and its group label. A group with no surviving cards disappears entirely rather than rendering empty.

Because the description is matched too, the useful searches are often not the card’s name:

• Typing domain surfaces General — the word appears nowhere in that card’s title, only in “Site title, domain, time zone, default language.” — and Emails as well, from “sender domains”.
• Typing 301 surfaces URL Redirects, from “301 redirect rules that keep old URLs working.”
• Typing automation surfaces all three cards in Automation & AI, because it matches the group label rather than any one card.

The honest counterpart: a word that appears in no title, no description and no group label returns the empty state, No settings match “…”. webhook, audit and timezone all do. That is a real answer rather than a broken search — settings you will not find explains what each of those absences means.

What the pills and dots mean

The small gray pill beside a card title is live data read from your workspace, not an illustration: 12 members, 8 types, 3 redirects. Five cards suppress the pill when the count is zero rather than showing 0 — Journey stages, URL Redirects, Forms, Emails, and Search Indexes. Team members, Page types and Labels always show a count, including zero.

The amber dot carries the accessible label Unpublished changes and appears on five cards only: General, Team members, Page types, Labels and Search Indexes. Those are the surfaces whose unpublished state the grid reads. Forms and Autolinks track unpublished work too, but the grid does not read it — it shows only on their own screens — so a change to a form, an autolink or a journey stage never lights a dot on this screen.

Cards you cannot see

A card is removed from the grid when your role fails the privilege behind it, and the underlying list request is never made — so the count it would have shown is never fetched either. Two administrators and one writer looking at the same workspace therefore see grids of different sizes.

A missing card is a permissions answer, not a missing feature. Who can see what reads the CMS from each role’s point of view, and roles and permissions is the ladder itself.

The settings map

If you know what you want to change and not which page explains it, this is the table to read. Fourteen cards, four groups, and the page that owns each one.

The What the card says column is the card’s own description text, quoted exactly — because that string is what the search box matches, so it is what you need in order to find the card. It is not always a promise the screen keeps; two of them describe more than the screen behind them does, and the linked page is the one that tells you what is actually there.

Two rows deserve their correction here rather than two pages later. The General card advertises a time zone and a default language; neither field exists on that screen or anywhere else in the CMS. The Emails card promises sender domains and suppressions; the screen behind it is a read-only list of email templates. Both are named again, with what to use instead, in settings you will not find.

Dynamic CTAs and Recommendations are two cards pointing at one route. Click either and you land on a screen titled Dynamic Calls To Action — one feature answering to two names on the grid. It is also the one screen in this table that is wholly plan-gated: without the Growth-tier entitlement the route renders an upgrade prompt instead of the editor. CI trust is gated differently: its list of registered trusts and their Revoke controls are there on every plan, and only the form that registers a new trust needs Growth, so a workspace that downgrades can still revoke what it already registered. Every tier boundary in the product is listed in one place, at feature availability by plan.

Sections inside General

Four more configuration surfaces have no card of their own, because they are sections stacked inside Settings → General rather than screens of their own.

The Documentation section is the largest of the four by a wide margin: layout, color theme, code theme, font, the light and dark logo pair, the top and bottom menu slots, the header button, the starting page and the tab groups your writers see in the editor all live there.

Inside a settings screen

Every sub-page renders the same header. A back-chevron and a Settings eyebrow that returns you to the grid, the screen’s own title, and a one-line description beneath it. To the right of that header sits an action slot, which is where a screen puts its New, Invite or Create control when it has one.

Five screens also put an amber Unpublished changes — Publish button in that slot when they have unpublished work and you hold deployment:publish: Forms, Team Members, Labels, Page Types and Autolinks. It is a shortcut straight to the Deploy tab. On Autolinks a reorder alone is enough to raise it, because the order of the list is published too.

General does not have one. It shows an amber dot beside each section title instead, so on that screen you watch the dots and go to Deploy yourself. Search Indexes is the same — dots on rows, no button.

Two screens are titled differently from the cards that lead to them, which is disorienting the first time: both Dynamic CTAs and Recommendations open Dynamic Calls To Action, and Billing & plan opens Plans & billing. Every other card opens a screen carrying its own name, give or take capitalization.

A /settings/<something> you have no privilege for, and any sub-route that does not exist, both render the CMS’s Not Found inside the settings frame rather than redirecting you away. The eyebrow still works, so the way back is always one click.

Settings that are not in Settings

Several things that feel like settings are configured elsewhere in the shell. This half of the map exists so you stop looking for a card that was never going to be there.

The gear that opens Settings, and the five other destinations on the rail beside it, are described together in touring the workspace. If you would rather have the field-by-field enumeration than this map, the settings field reference lists every screen’s fields and the permission each one needs.