> ## Documentation Index > Fetch the complete documentation index at: https://docs.invoca.com/llms.txt > Use this file to discover all available pages before exploring further. # Settings view > Configuration grouped into independent sections, on one scrollable page, committed as one unit from a fixed footer. ## What it is A page that configures an **already-existing** subject's standing settings — an account's settings, a campaign's settings, an integration's configuration — grouped into independent sections a reader visits selectively over that subject's ongoing life, rather than filled in once during that subject's creation. This is the concrete answer to [CRUD: Create](/invoca-design-system/patterns/crud/create#constraints)'s own rule: *"A form with several independent sections is one page with a Table of Contents, not a Wizard."* Settings view is what that Table of Contents looks like when the subject is standing configuration rather than a form being filled in once. Settings are almost always settings **of** something — an account, a campaign, an integration — never a freestanding subject of their own. `Breadcrumb` back to that thing is required; see [Header — Left](#header-left). You are building one if the page's sections are independent (no fixed order, each meaningful on its own) and the subject already exists and will be reconfigured repeatedly over time, not created once and then left. A page that is filled in once toward a single commit, for an object that does not yet exist, is [Full-page form](/invoca-design-system/views/full-page-form) even when it also has several independent sections — see [Choose something else when](#choose-something-else-when). ## Region vocabulary This archetype adds no regions to the [page frame](/invoca-design-system/views/overview#the-page-frame). It reuses a structural pattern [Full-page form](/invoca-design-system/views/full-page-form#contents-the-form) already established for independent sections on one page — an in-page navigation aid inside `Contents`, not a frame region — rather than inventing a second answer to the same shape of problem. Two terms are worth naming even though neither is a frame region: | Region | Also called | The system uses | | ----------------------------------- | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | One labeled group of related fields | Group, panel, block | **Section** (this archetype's term, following [Full-page form](/invoca-design-system/views/full-page-form#region-vocabulary)'s own usage — not a system export) | | In-page navigation between sections | Table of contents, section nav, jump links | Not a named region — an anchor nav inside `Contents`, the same pattern [Full-page form](/invoca-design-system/views/full-page-form#region-vocabulary) names | ## Choose this view when * The subject already exists and is being configured on an ongoing basis, not created for the first time. * Configuration breaks into independent sections — notification preferences, billing, API access — with no fixed order between them. * A reader typically comes back to change one section at a time, on separate occasions, rather than filling in the whole page once. ## Choose something else when | If the page also needs to… | Use | Why | | -------------------------------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Configure only one thing — nothing to group into sections | [Full-page form](/invoca-design-system/views/full-page-form) | Full-page form's own `Contents` already collapses to a plain form with no anchor nav once there is only one section — see [that page's Regions table](/invoca-design-system/views/full-page-form#regions). Settings view's grouping has nothing to organize once there is only one thing to configure. | | Be filled in once, toward a single commit, for an object that does not yet exist | [Full-page form](/invoca-design-system/views/full-page-form) | That page already resolves several independent sections onto one page with an anchor nav — for exactly the bounded, one-time case. Settings view is the same structural shape turned to the opposite case: standing configuration edited piecemeal, indefinitely — which is why its footer is fixed rather than sitting at the end of the scroll, see [Footer](#footer). | | Walk the reader through sections that genuinely depend on each other, in order | [Wizard](/invoca-design-system/views/wizard) | Order-dependent sections need a Wizard regardless of which archetype would otherwise hold them — the same rule CRUD's own Create page already states. | ## Regions | Region | Required | Landmark | Contains | | --------------------- | ----------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `Header` — `Left` | Yes | `banner` | `Title` naming the scope being configured. `Breadcrumb` back to the thing these settings belong to — required, not optional, on this archetype. | | `Header` — `Right` | No | — | A secondary, non-committing action if one exists. Never the view's commit — that lives in `Footer`. | | `Header` — second row | No, in the default case | `tablist` only if the Tabs threshold below is met | Nothing, in the default case — see [Header — second row](#header-second-row). | | `Controls` | No | `search` when primarily search | A search box across all settings, when the number of fields makes one worth having — not required by this archetype. | | `Contents` | Yes | `main` | The sections, each a labeled group of fields, plus an anchor nav when there is more than one. | | `Footer` | Yes | `contentinfo` | The view's commit and cancel, fixed to the viewport — see [Footer](#footer). | ## What fills each region ### Header — Left | Slot | Use | Constraint | | ---------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Title | `Title` | **Required.** Names the scope — "Notification settings," "Campaign settings" — not a bare "Settings" with nothing to anchor it. | | Breadcrumb | `Breadcrumb` | **Required on this archetype**, pointing to the thing these settings configure. Settings are settings *of* an account, a campaign, an integration — omitting the breadcrumb strands the reader with no path back to what they're configuring. | ### Header — second row The default state is **nothing** — per [Views overview](/invoca-design-system/views/overview#header-tab-bar)'s own three states (nothing, tabs, filters), Settings view's header carries no second row in the common case. The Table of Contents is not a header occupant at all; it lives inside `Contents`, following [Full-page form](/invoca-design-system/views/full-page-form#contents-the-form)'s precedent — see [Contents — sections and navigation](#contents-sections-and-navigation) below. **Why not a tab bar**, when [Views overview](/invoca-design-system/views/overview#header-tab-bar) already defines one as exactly "a section of the page's subject" — which a settings section plainly is. The reason is the frame's own rule that exactly one `TabPanel` is visible at a time. That property is the wrong fit here, even though the section-of-a-subject test passes. A reader configuring settings often needs to see two related sections at once — checking who's on the notification list while editing the escalation rule that pages them — or wants to search across every setting at once, not just the one section currently active. A tab bar hides everything but the active panel by design; an anchor nav inside `Contents` keeps every section on the page, reachable by scroll and by search, which is the property this archetype actually needs. **Tabs are still the right call when sections are numerous and truly unrelated** — each large enough to be worth its own screen, not just a labeled group of fields on one coherent configuration surface. That is the same threshold [Progressive disclosure](/invoca-design-system/patterns/progressive-disclosure#structure) already states for its own "Settings tab over Accordion" variation: a secondary area large enough that most users never open it is worth a dedicated tab, not a scroll-triggered reveal. "Billing" and "Notification preferences" on one account settings surface are related enough to stay on one page; an entire "Integrations" configuration area with its own object model might cross that threshold and deserve its own tab, its own URL, and its own Settings view underneath it. ### Contents — sections and navigation Each section is a labeled group of related fields — a heading, then its fields, visually distinguished the same way [Full-page form](/invoca-design-system/views/full-page-form#contents-the-form) already specifies: headings, dividers, or grouped cards, never hidden behind tabs or steps. An anchor nav, when there is more than one section, is a shortcut to a section, never a gate in front of it — clicking an entry scrolls to that section; it never hides the others. This is the same structure [Full-page form](/invoca-design-system/views/full-page-form#constraints) already establishes; Settings view follows it rather than re-deciding it. | Slot | Use | Constraint | | ------------------ | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | | A section | Heading, then its fields | Independent of every other section — no fixed order, and no section depends on another's value to make sense. | | Section anchor nav | An in-page jump list | Present once there is more than one section. Scrolls to a section; never hides the others — the same rule Full-page form's own anchor nav follows. | **Whether a section starts collapsed follows [Progressive disclosure](/invoca-design-system/patterns/progressive-disclosure#when-this-applies)'s own threshold directly, rather than a rule invented here**: collapse a section only if it is genuinely secondary — used by a minority of readers in a minority of sessions — and never collapse the section a reader most likely came to this page to change. A settings page whose every section is something most accounts touch regularly should show every section open by default; disclosure earns its place only for the sections most accounts never adjust. ### Footer **Required, and fixed to the viewport.** Every section on this page configures one subject, so the whole view is the unit of commit and one footer covers it — the frame's `Footer`, holding the view's commit and cancel. No section carries a Save of its own. It is fixed rather than static because a reader arrives to change one section, which may be anywhere on the page. A footer at the end of the scroll is a journey away from the edit, which is the distance that makes a per-section button look like the obvious fix. Fixing it keeps the commit in reach of whichever section the reader came for. The full decision, and what changes when configuration is scoped to a single container instead of a whole view, is in [Footers](/invoca-design-system/patterns/footers). | Slot | Use | Constraint | | ----------------- | --------------------- | -------------------------------------------------------------------------------------------- | | Leading | — | Empty. A backward action belongs to a sequence, not to standing configuration. | | Trailing — Cancel | `Button` **tertiary** | Discards every uncommitted edit on the view. | | Trailing — commit | `Button` **primary** | Labeled for the action, never the section — "Save changes". At most one primary on the view. | ## Responsive and density behavior Titan is desktop-first — most surfaces live at `lg` and `xl`, and `xs`/`sm` are rarely exercised (see [Layout & grid](/invoca-design-system/foundations/layout-and-grid#breakpoints)). What follows is proposed with that in mind. | Breakpoint | Collapses | Stacks | Dropped | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------- | ---------------------------------------------------------------------------- | | `md` and below | The anchor nav collapses from a persistent side rail into a dropdown or a collapsible list above the sections — the same collapse [Full-page form](/invoca-design-system/views/full-page-form#responsive-and-density-behavior) already specifies | Multi-column field layouts within a section stack to one column | Nothing — every section stays reachable; only the nav's presentation changes | | Compact density | Field and section spacing only | — | — | ## Accessibility The page-level decisions are the frame's, and they apply unchanged — see [Views overview → Accessibility](/invoca-design-system/views/overview#accessibility). One `main`, one `h1` on `Title`, region order matching visual order. What is **specific to this archetype**: * **Each section heading is a real heading**, descending from `Title`'s `h1` without skipping a level, so a screen-reader user outlining the page sees the same structure the anchor nav exposes visually — the same requirement [Full-page form](/invoca-design-system/views/full-page-form#accessibility) already states. * **The anchor nav is a navigation landmark with an accessible name** — "Settings sections," not "Navigation" — whose links move focus to the target section's heading, not just scroll position. Same reasoning as [Full-page form](/invoca-design-system/views/full-page-form#accessibility). * **A collapsed section's trigger states what it reveals**, and a validation error inside a collapsed section forces it open and is announced — the same rule Progressive disclosure already states, applied here rather than restated. * **The footer's commit and cancel carry accessible names that name the action, not the section** — "Save changes," not "Save notification settings" — because there is one commit for the whole view and nothing to disambiguate it from. * **A failed commit moves focus to the first invalid field**, in its own section, and the failure is announced via a live region or the error text's association to that section — not shown only visually. With one footer the field that blocked the commit is frequently off-screen from the button that was pressed. ## Constraints | ID | Constraint | Rationale | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **TITAN-SETVIEW-01** | `Breadcrumb` is required in `Header` — `Left`, pointing to the thing these settings configure. | Settings are settings *of* something. A page naming only "Settings" with no ancestry strands the reader with no path back to the account, campaign, or integration it belongs to. | | **TITAN-SETVIEW-02** | Independent sections get a Table of Contents inside `Contents`, not a tab bar in the header's second row — unless sections are numerous and truly unrelated, each substantial enough to be worth its own screen, per [Progressive disclosure](/invoca-design-system/patterns/progressive-disclosure#structure)'s own "Settings tab" threshold. | A tab bar shows exactly one panel at a time, which hides related settings from each other and blocks searching across them. An anchor nav keeps every section visible and searchable, which is what a reader configuring related settings needs. | | **TITAN-SETVIEW-03** | A section starts collapsed only when it meets [Progressive disclosure](/invoca-design-system/patterns/progressive-disclosure#constraints)'s own threshold for genuinely secondary content; a section most readers actually came to change starts expanded. | This archetype does not re-decide Progressive disclosure's own threshold, it applies it. | | **TITAN-SETVIEW-04** | *Superseded by TITAN-SETVIEW-08.* Each section commits independently, with its own Save and Cancel scoped to that section's fields; the page carries no page-level commit. | Retired when the view became the unit of commit. Kept so a citation still resolves to the rule it meant. | | **TITAN-SETVIEW-05** | *Superseded by TITAN-SETVIEW-09.* Cancelling a section reverts only that section's uncommitted edits, never any other section's. | Retired with TITAN-SETVIEW-04, whose section-scoped commit it depended on. | | **TITAN-SETVIEW-06** | A validation error inside a collapsed section forces that section open and is announced. | Per [Progressive disclosure](/invoca-design-system/patterns/progressive-disclosure#constraints) — the same rule that page states, applied here rather than re-decided. | | **TITAN-SETVIEW-07** | A failed commit keeps every edited field in its unsaved state, with the error rendered against the section it came from. It never silently reverts to the last-saved value. | Reverting on failure discards a correction the reader believed they'd made, with no way to recover it — the same reasoning Inline editing applies to its own failed saves. | | **TITAN-SETVIEW-08** | The view commits as one unit, from a single fixed `Footer`. No section carries its own Save and Cancel. | Every section on this page configures one subject, so the whole view is the unit of commit. A commit per section splits that unit into several and leaves "am I done?" unanswerable from the screen. | | **TITAN-SETVIEW-09** | Cancel in the footer discards every uncommitted edit on the view, never one section's alone. | There is one unit of commit, so there is one thing to discard. A section-scoped revert would imply a section-scoped save, which this archetype does not have. | ## Composed example ``` ┌───────────────────────────────────────────────────────┐ │ Acme Inc. / Settings │ ← Header: Left (Breadcrumb, Title). No second row. ├───────────────────────────────────────────────────────┤ │ ┌───────────┐ ┌─────────────────────────────────────┐ │ │ │ Profile │ │ Profile │ │ │ │ Notif. │ │ Name: [_______________________] │ │ │ │ Billing │ │ │ │ │ │ API keys │ │ │ │ │ └───────────┘ │ Notifications │ │ │ │ ▸ Advanced routing (collapsed) │ │ ← Progressive disclosure │ │ ... │ │ │ │ ... │ │ │ └─────────────────────────────────────┘ │ ├───────────────────────────────────────────────────────┤ │ [Cancel] [Save changes] │ ← Footer: fixed, one commit for the view └───────────────────────────────────────────────────────┘ No section carries a Save — the whole view commits together. ``` ## Related * [Views overview](/invoca-design-system/views/overview) — the frame this archetype fills * [Full-page form](/invoca-design-system/views/full-page-form) — the sibling archetype for the same "several independent sections, one scrollable page" shape, applied to a bounded, one-time commit instead of standing configuration * [CRUD: Create — TITAN-CREATE-03](/invoca-design-system/patterns/crud/create#constraints) — the constraint this page resolves concretely * [Progressive disclosure](/invoca-design-system/patterns/progressive-disclosure) — the collapsed/expanded threshold this page applies rather than re-deriving * [Footers](/invoca-design-system/patterns/footers) — which surface owns the commit, and why this one belongs to the view rather than its sections * [Inline editing](/invoca-design-system/patterns/inline-editing) — the alternative when the unit of change is a single field rather than the view * [Wizard](/invoca-design-system/views/wizard) — where sections genuinely depend on each other in order ## Why it works this way **The anchor nav is borrowed, not reinvented, because the underlying shape is identical.** [Full-page form](/invoca-design-system/views/full-page-form#why-it-works-this-way) already worked out that independent sections belong on one scrollable page with a jump list rather than behind tabs or steps, for the reason that hiding them teaches a relationship — order, or boundary — that independent sections don't have. Settings view's sections are just as independent of each other; re-deriving a second answer to the same question would only invite the two pages to quietly drift apart over time. **The footer is fixed, and the reason is where the reader edits.** A [Full-page form](/invoca-design-system/views/full-page-form) is filled top to bottom and ends where its footer is, so a static footer is in the right place by construction. Settings view's subject already exists and gets reconfigured indefinitely, in separate visits, by readers who came to change one section and have no reason to re-touch the rest — so the edit can be anywhere on the page, and a footer at the end of the scroll is a journey away from it. Fixing the footer puts the commit within reach of whichever section the reader actually came for. The unit of commit is still the whole view: every section on this page configures one subject, so one footer covers them all — see [Footers](/invoca-design-system/patterns/footers). ## Status | | | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Constraints** | Proposed. `TITAN-SETVIEW-01` through `-09`; `-04` and `-05` superseded by `-08` and `-09`. | | **Decided** | One fixed footer for the view, and no section-level commit. | | **Provenance** | Built from the constraints Views overview, CRUD, and Progressive disclosure establish, and from the sibling Full-page form archetype. No audited product screen backs the section structure. | | **Open** | The composed example is a structural diagram; replace it with a live embed once the archetype ships. Footer behaviour on partial validity and multi-section cancel is undecided — see Footers. |