Creating a resource
Provision a new resource through a guided, sectioned form with a single clear commit.
Creating a resource walks the user from an empty form to a committed resource. Input is grouped into sections, validation waits until the user is ready, and a single, clearly-labelled action commits the whole thing — so the user always knows what they're making and when it happens.
When to use this pattern
How to use the pattern
A stepper-guided wizard
Creating a resource is one sectioned form, committed by a single action. Sections stack on one page; a stepper rail summarizes each, tracks where the user is, and flags per-section error counts — clicking a step jumps to it. A single-section create hides the rail. The commit action stays in reach in a sticky bar throughout, and validation holds until the user is ready.† Reduce cognitive load † Orient users in long flows † Minimize distance to important actions
Validation & errors
Validation holds until the user is ready to commit, then surfaces every problem in one pass and points at exactly what to fix — never nagging mid-entry.† Validate at the right moment
Errors
Validate when the user is ready, not as they type — required fields on submit, format-sensitive fields on blur and then live. On submit, a summary at the top lists every error and jumps to the field; the step rail and the offending section card each flag their error count. Each error clears the moment its field becomes valid — even after a failed submit — so the summary and counts shrink as the user fixes things. The Create action stays enabled, and a failed submit routes its errors into the same summary — never a toast.† Reduce cognitive load † Make errors recoverable
Confirmation
On success, confirm and move the user forward — to the new resource, or a fresh form to create another. On failure, keep everything the user entered and surface the error in context, never a transient toast.† Think in states † Communicate side effects
The same form, submitted invalid — every problem surfaced at once, the offending sections flagged, and a summary at the top.
Conditional sections
Optional Applies when a resource has a type or kind that changes which other fields it needs.
A discriminator field un-gates the fields that depend on it — hidden until the choice is made, then revealed. The revealed field's own options can be filtered by the discriminator's value, so the user only ever sees choices that the discriminator actually allows.† Reveal complexity progressively † Guard unsaved work
Mind & fuel
Resource identity
Optional Applies when a resource needs a machine id distinct from its display name.
Derive the id from the display name as the user types — a hyphenated slug, seeded with a random suggestion — and stop deriving the moment they edit it directly. The derived value is a baseline, not an edit, so it never trips an unsaved-changes prompt.† Reduce cognitive load
Resource dependencies
Optional Applies when a resource references exactly one required other resource.
Handle the whole dependency in place: pick an existing one, create a new one inline in a drawer running that resource's own form (the new one auto-selects so the user keeps their place), edit the selected one in the same drawer, or jump out to manage them on their own list page — so dealing with a dependency never derails the flow.† Think in states † Keep actions near what they affect † Minimize distance to important actions
Selecting multiple resource dependencies
Optional Applies when a resource references a required multiple of another resource.
The same pick-an-existing or create-inline flow against a multi-select; each selected reference can be edited in place in a drawer.† Reduce cognitive load † Keep actions near what they affect
Tricks
Behavior
This pattern delivers one goal: provision a new resource with confidence — always knowing what's being created, and exactly when it commits. The checks below are how you verify an implementation delivers it.
- At rest —
The form opens empty (or with safe defaults) with every section visible, so the user sees the full shape of what they're creating. The commit action is present from the start — never hidden until the form is valid.
- Sectioned & oriented —
Fields are grouped into labelled sections. A multi-section form shows a stepper that marks the current section, shows progress, and lets the user jump between sections; a single-section form shows no stepper.
- Quiet until ready —
Validation holds while the user types — nothing is flagged wrong until they try to commit. The user is never nagged mid-thought.
- Commit in reach —
The commit action stays visible as the user scrolls; they never hunt for how to finish.
- Resource identityOptional —
If the resource has a machine ID, it auto-derives from the display name as the user types — seeded with a random suggestion — and stops the instant they edit the ID directly. The auto-filled value never trips an unsaved-changes warning.
- Conditional sectionsOptional —
A type or kind choice reveals the fields that depend on it; they stay hidden until chosen. A dependent field is not rendered until the field it depends on is populated.
- Resource dependenciesOptional —
A required reference handles both states: when none exist, an empty state names the gap and offers to create one inline; when some exist, the user picks or creates another and can manage them in a separate tab — without derailing the flow.
- Linked resourcesOptional —
Where the resource points at another, the user can pick an existing one or create a new one inline — in a drawer running that resource's own form — and the new one is selected automatically, so they keep their place.
- Editable linked resourcesOptional —
A selected reference exposes an edit affordance that opens the same drawer in edit mode, so the user changes a linked resource where they reference it — without leaving the create flow.
- The commit —
A single action commits the whole form, labelled with what it makes (verb + noun). It blocks duplicate submits and shows it's working while saving. Until it's pressed, nothing is saved — and the UI never implies otherwise.
- Errors surface together —
Submitting an invalid form reveals every problem in one pass: each offending field inline, its section flagged, and a summary at the top. The user can click a summary entry to jump to the field; fixing fields clears their errors as they go. No problem appears only after the previous is fixed.
- Success —
The user gets clear confirmation and is moved forward — to the new resource, or a fresh empty form to create another.
- Failure —
Every value the user entered is preserved, and the error appears in context (the same top-of-form summary) — not a transient toast that vanishes.
- Leaving —
Cancelling, going back, or navigating away with unsaved edits warns before discarding; a clean, untouched form leaves with no prompt.
- Accessibility —
Every field has a visible, associated label. On commit, focus moves to the first problem. The commit action works by keyboard and is never silently disabled. Progress and completion are announced, not conveyed by a spinner alone.
Content & copy
The commit action names what it creates, and confirmation reads as done. (See the UX text style guide.)
- Primary action is a specific verb + the resource name, never "Submit" or "Done".
- Placeholders describe the input; fields start empty.
- Success confirmation reads as done — past tense and plain.
- Vague commit labels: "Submit", "Done", "OK".
- Padded confirmations — "successfully!" or trailing exclamation marks.
- "E.g." or "Example:" inside placeholder text.
Accessibility
- Every field has a visible, associated label; placeholders never replace labels.
- On submit, focus moves to the first invalid field and scrolls it into view.
- The create action is reachable by keyboard and never silently disabled.
- Progress and completion are announced, not conveyed by a spinner alone.
Related patterns
- Editing a resource — changing it later, which shares validation.
- Resource detail — where the created resource lands.