Skip to main content
Exemplar section — first pass. Like the rest of Patterns, this is a proposal for review, not established policy. No audited Invoca screen backs it — it is built from general interaction-design practice and from the real components and views Titan already ships. See Coverage, stated honestly.

What CRUD governs

Every object in the product — a campaign, a tag, a routing rule, a team member — gets created, read, updated, and deleted somewhere. Those four operations recur so often that it’s tempting to treat “how” as already answered: a form, on a page. It isn’t one answer. A tag and a campaign are both “created,” and putting both behind the same full-page form either drowns the tag in ceremony it doesn’t need or starves the campaign of room it does. This section’s job is the surface decision, not the layout. It decides whether an operation happens on a full page, in a drawer, in a modal, or in place — not how that surface is laid out once chosen. Four sub-pages cover the operations individually; this page holds the decision framework they share.
Full page, drawer, modal, and inline are examples, not a fixed menu. They’re the surfaces Titan already ships components or views for, so they make the tree concrete. Nothing here requires that every operation resolve to one of exactly these four — if a real case needs a fifth, that’s a gap to raise, not a rule this page is blocking.

Vocabulary

A surface is the container an operation happens inside — the thing that has its own lifecycle (open, dismiss, navigate away) independent of the object being acted on. Four axes decide which one fits, in the order they’re worth asking: Sequence is a modifier, not a fourth vote. A “yes” on Sequence doesn’t pick a surface by itself — it says the surface that Permanence, Density, and Continuity already chose needs a visible step indicator inside it. See TITAN-GAP-26: the design library has already drawn what that looks like — a numbered step header paired with a Workflow template — and nothing in code builds it yet. Any sequential surface this section recommends is a proposal against that same undecided component, not a claim it exists.

Choosing a surface

This is the shared shape. Create walks it in full depth with real examples and constraints; Update reuses the same tree and covers what’s different about acting on an object that already has data. Read answers a narrower version of the same question, choosing between viewing surfaces Titan already has a View archetype for. Delete has no page of its own here. It is governed almost entirely by Destructive confirmation already — that page owns the tier decision, and now owns the CRUD-specific additions (cascades, bulk delete) too, folded into its own Variations and Constraints. A fourth “Delete” page that mostly said “see Destructive confirmation” would have been indirection with no real content behind it; the two are consolidated instead.

Coverage, stated honestly

Choosing where to look

Create

The full decision tree, with real surfaces mapped to real components.

Read

Viewing an object — full detail page, drawer preview, or inline expansion.

Update

What changes when the object already has data in it.

Destructive confirmation

CRUD’s Delete operation, in full — including cascades and bulk delete.

Constraints

Views overview, for the page frame a full-page surface is built from. Destructive confirmation, Bulk selection, and Inline editing — each already answers part of one CRUD operation and is cited, not re-derived, on the relevant sub-page.

Why it works this way

A decision tree, not a fixed rule, is the point. A rule that says “objects are created on a full page” is simple and wrong the first time someone needs to create a tag without leaving the form they were filling out. A rule that says “use whatever fits” is flexible and useless — it gives the next ten teams ten different answers. The tree is how the platform stays flexible on the actual axes that matter — how permanent, how dense, how connected to its context an object is — while still giving the same answer to the same question every time it’s asked. Read and Delete lean on what already exists because they should. Writing a second decision tree for viewing or removing an object, when Views and Destructive confirmation already answer most of it, would be inventing a distinction that isn’t there. Where a CRUD operation is genuinely a new decision — Create — it gets the full page. Where it mostly isn’t, the page says so and points at the real answer instead of manufacturing a false one.

Create

The decision tree for where a new object gets created — full page, modal, drawer, or inline — based on permanence, density, and continuity, not habit.

Read

Viewing one object in detail — full Detail view, Drawer preview, or inline expansion — based on how much the reader needs right now.

Update

What changes once an object already has data — prefill, partial versus whole-form save, dirty-state tracking, and concurrent edits.
Last modified on September 2, 2026