Skip to main content

​
The problem

Create decides where an object is born. Once it exists, editing it raises questions Create never had to answer: the surface opens with values already in it, not a blank form; some edits are small enough to commit the instant they’re made, and others need everything held until an explicit Save; the surface has to know whether anything has changed at all; and the object might not be exactly as it was when the surface opened, if someone or something else touched it in the meantime. None of that is a new surface decision. It’s what happens once the surface Create’s tree already chose is holding an object that isn’t new anymore.

​
Choosing a surface, revisited

CRUD overview already states the default: the same object type uses the same surface for Create and Update, unless a stated reason differs. Create already names the one legitimate case where it does — this page resolves it rather than inventing a second answer. A quick-create Modal is optimized for speed of creating something, not for that object’s whole life. Once the object exists, it has already earned whatever permanence its type implies — and its ongoing edit surface is the surface that permanence calls for, even if the object was born in a lighter one.
The exception is about the object type, not the individual object. A Tag is created in a two-second Modal and is still edited through that same lightweight surface for as long as it exists — a Tag never earns more permanence than that, so there’s nothing to graduate to. A saved filter is also quick-created in a Modal, but if it later becomes something people treat as a shared, first-class asset, its edit surface moves to the fuller one — Drawer or full page — at that point, not before. A Campaign or an integration never faces this question at all: both are already full-page objects from the moment they’re created, so Create and Update land on the same surface with no exception needed.

​
When this applies

  • The object already exists and its data is being changed, not authored for the first time.
  • The object was reached from Create’s “duplicated from an existing one” case — the surface is Create’s tree; the values arriving pre-filled from a template is this page’s concern.

​
When it doesn’t

​
Structure

​
Behavior

​
Constraints

​
Content

​
Accessibility

  • Opening the edit surface moves focus to its first field once values have loaded, matching Create’s own behavior for a Modal or Drawer. Moving focus before values arrive would land the reader in a field about to change under them.
  • A failed save’s inline error is announced per Inline editing’s rule for a single field, or Form validation’s rule for a whole-surface save.
  • The concurrent-edit re-confirmation states the specific change in its accessible description, not through color alone — the same requirement Destructive confirmation already states for its own body text.

​
Variations

​
Anti-patterns

Editing a Tag on a full page because “editing deserves more room than creating.” The Tag’s permanence hasn’t changed just because it now exists — it never earned a fuller surface, so its edit stays on the same one it was created on. Reopening the whole edit surface for a one-field change that Inline editing already covers. Adds a navigation and a full form for a change that takes one field and one second. Committing a multi-field edit field-by-field as each one changes, with no single Save. Leaves the object in a partially-applied combination of values nobody chose as a set. Silently discarding a save because the object changed on the server, with no way to see what changed. The reader loses their edit with no explanation — the same failure mode as a dialog that closes on failure instead of showing what went wrong. CRUD overview, for the shared axes and TITAN-CRUD-02, which this page resolves. Create, whose surface this page reuses and whose Variations table first raised the pointer this page answers. Read, the sibling CRUD operation. Inline editing, for a single field’s whole behavior. Loading & skeletons, for the prefill-loading treatment. Destructive confirmation and Form validation, cited above rather than restated.

​
Status

Exemplar page — first pass. This is a proposal for review, not established policy — see CRUD overview. This page reuses Create’s surface tree rather than walking it again — see Choosing a surface, revisited — and covers only what’s genuinely different once an object already has data in it.
Last modified on September 28, 2026