Skip to main content

​
What it is

A page whose subject is one record — one campaign, one number, one routing rule — shown in full: its own attributes, and the data attached to it. It is where CRUD: Read’s decision tree lands when a reader needs the object’s full context, possibly to act on it next, and where List view sends a reader who has already found the one row they wanted. You are building one if the page answers “what about this one?” A page that answers “which of these?” is a list view.

​
Region vocabulary

This archetype adds no regions. It uses the page frame as published, and the frame’s vocabulary is the vocabulary here — including the header’s second row, which this archetype is the primary user of for a tab bar.

​
Choose this view when

  • The reader already knows which record they want, and needs everything about it — not a subset — per CRUD: Read’s “full context, possibly to act on it” case.
  • The record has enough attributes or related data that a preview surface would cramp it — see CRUD: Read’s own tree for what falls short of this (inline expansion, Drawer preview).
  • Losing sight of the list the reader came from is an acceptable cost, because the record is now the whole job.

​
Choose something else when

​
Regions

​
What fills each region

​
Header — Left

Title is the record’s own name or identifier — the actual campaign name, the actual phone number — never a generic label like “Campaign Detail.” A reader arriving from a link, a search result, or the list’s own row action should see the same name they clicked. Breadcrumb points back to the collection this record belongs to — the list view it was most likely reached from. Status appears only when the record itself has a state that changes what can be done to it — draft, active, paused — following Views overview’s own rule that Status is for the page’s subject, never implied by which actions are enabled.

​
Header — Right

Page-level actions on this specific record go here — Left says what the record is, Right says what can be done to it. This is the surface CRUD: Update and Destructive confirmation attach to:
  • An Edit action opens whatever surface CRUD: Update selects for this record’s object type — a Drawer, a full page, or inline editing on individual fields. Which surface that is is Update’s decision, not this archetype’s — the same relationship List view already establishes between itself and CRUD: Create.
  • A Delete action opens Destructive confirmation’s dialog, at whichever tier that page’s own decision tree selects for this record’s consequences.
At most one primary action. Collapse anything past three actions into a Menu, per Views overview.

​
Header — Tabs versus a scrolling page

A detail view’s body is either a single scrolling page or tabbed sections, never both at once, per the header’s second-row exclusivity already stated in Views overview. This page cites that model rather than deriving a second one. The threshold: tab when the record’s sections are independently substantial enough that a reader wants to jump to one without scrolling past the others. A campaign with an overview, a routing configuration, and a call history each deep enough to scroll on its own is tabbed. A record whose attributes fit in a screen or two of scrolling, with nothing a reader would want to jump past, stays a single Contents region with grouped sections and anchor headings. There is no fixed count of attribute groups that forces tabs — it is whether scrolling past a section costs the reader something. A record with four short groups and one long call history often reads better as one scrolling page with the long section last, not four tabs for one page’s worth of content. When tabbed, each tab is a section of this record’s own data — Overview, Routing, History — never an action or a filter. Selecting a tab changes the URL, so a specific section of a specific record is linkable and survives a reload. The whole record is one Contents region. When the page is tabbed, each tab’s content is a TabPanel inside that same Contents — the tabs partition one region, they do not create additional ones. Inside it, two kinds of content recur:
  • Attribute groups — the record’s own fields, grouped by what they describe (identity, configuration, targeting) rather than listed flat. Grouping is a per-page decision; the system does not prescribe group names.
  • Related data — a collection attached to this record but not the record itself: a campaign’s calls, a routing rule’s change history, a number’s assigned campaigns. This renders as a compact Table or List embedded in a Contents section.
A related-data table here is not the same archetype as a full List view for that same collection. List view’s own Choose something else when table already names this page as the destination for “show one record’s attributes and related data” — this section is that destination. The embedded table is scoped to this one record (a campaign’s calls, not all calls), is denser, and typically drops filtering and bulk actions that the collection’s own list view would carry. A “View all” affordance on the embedded table can hand off to that collection’s full list view, pre-filtered to this record, when the reader needs the full apparatus. Absent by default. Most attribute viewing has no single, whole-page commit — a reader looks at a record, they do not submit it, per the same reasoning List view gives for its own footer. A page-level footer applies only when the whole page is inline-editable as a unit — every field open for editing at once, with one Save and one Cancel for the entire record. This is rare. When one container on the page is configurable and the rest is read-only, the footer belongs to that container, not to the page — a static footer at the foot of the panel that holds those fields, committing exactly them. The page carries none. That is the same rule as the page-level case reaching a different answer, because the unit of commit sits inside the container rather than spanning the view — see Footers. The far more common case, a single field the reader wants to change without leaving the page, is Inline editing’s territory: it commits per-field, with no footer at all.

​
Responsive and density behavior

Titan is desktop-first — most surfaces live at lg and xl, and xs/sm are rarely exercised (see Layout & grid). What follows is proposed with that in mind.

​
Accessibility

The page-level decisions are the frame’s, and they apply unchanged — see Views overview → Accessibility. One main, one h1 on Title, region order matching visual order. What is specific to this archetype:
  • The Title is the record’s own identifying name, so a screen-reader user landing on the page hears what record they’re on immediately, without needing Breadcrumb or Status read first.
  • Attribute groups get their own heading, descending from Title’s h1 without skipping a level, so the page’s outline reflects its grouping the same way its visual layout does.
  • A tabbed detail view follows the tab bar’s own accessibility requirements in Views overview — a named Tabs region, each tab’s id/aria-controls pointing at its panel, and the panel’s own heading inside it (a tab label is not a heading, per that section).
  • The related-data table’s accessible name identifies the relationship, not just the collection — “Calls for this campaign,” not “Calls” — so a screen-reader user can tell it apart from that collection’s own full List view if they’ve visited both.

​
Constraints

​
Composed example

No live embed exists yet. Per this page’s own rule, a composed example should be a real screen or a live embed rather than a static image — the diagram below is structural (region names and what’s in them, no measurements or visual styling) for exactly that reason, the same way every Structure diagram in Patterns is. Replace it with a live embed the first time this archetype is built.
  • Views overview — the frame this archetype fills
  • CRUD: Read — decides when this view is the right destination
  • CRUD: Update — decides what surface the edit action opens
  • Destructive confirmation — the delete action’s destination
  • Inline editing — the more common answer for a single field’s change
  • List view — where a record’s reader most often arrives from
  • Split view — a narrower version of this content model, alongside the list it came from
  • Table · List — what fills a related-data section

​
Why it works this way

The record is the whole page, so its actions live in one place. A page that mixes the record’s own actions with actions on its related data — deleting a call from inside the campaign’s detail view, say — asks the reader to track two different “what can I act on here” answers on one screen. Keeping Header → Right reserved for actions on the page’s own subject, and letting each related-data table carry its own scoped row actions if it needs any, keeps that answer to one per region. Tabs are a threshold decision, not a default. A detail view that reaches for tabs before a section has earned independent scrolling produces a record split into three shallow screens instead of one page a reader can skim in a single scroll. The cost of tabbing too early is not visual — it’s that a reader who wants to check two facts in different sections now pays for two navigations instead of one scroll.

​
Status

Exemplar page — first pass, entirely proposal. No audited Invoca screen backs this page — Titan’s design library was not available while writing it. It is built from general interaction-design practice and from the constraints Views overview, CRUD: Read, CRUD: Update, and Destructive confirmation already establish. Treat every constraint below as a starting point to check against real product screens, not as a rule already enforced.
Last modified on September 17, 2026