Export flow

When to use

Standalone export forms: dataset → file → delivery. Sync (download now) or async (email when ready). Distinct from admin-keys-and-export (compliance + workspace migration; always async) and from a single "Download CSV" button (no choices to make).

Sync — download now

Small datasets (< 10 k rows). User picks format, browser downloads on click. Submit button copy = the verb ("Download CSV"); format-picker change updates the button label.

Async — email when ready

Large datasets (≥ 10 k rows / known-slow exports). Submit queues a job; the user gets an email with a download link when the archive is ready. The form acknowledges the latency up front in an info alert + uses the verb "Request" instead of "Download".

Choice — download vs email

When both make sense (medium datasets, user preference matters). Radio choice up top toggles which submit verb fires; email field hides when "download" is selected.

Composition rules

• Submit-button verb mirrors delivery — "Download CSV" for sync, "Request export" for async. Never "Submit" — the verb tells the user what happens next.
• Format picker drives submit label — change the format from CSV to JSON, the button copy updates to "Download JSON". Removes ambiguity ("what am I getting?").
• Async exports announce the latency — info alert with the expected wait + delivery channel. "Up to 24 hours" is fine; silent spinners are not.
• Show the dataset size up front — the description slot carries row count / data range / filter context so the user knows scope before submitting.
• Compose with — wrap in <modal-ui> for in-context "Export…" affordances, OR render inline in a settings panel. The form composes; the surface choice is yours.

Cross-references

• admin-keys-and-export — compliance / workspace-migration export (always async, GDPR / SOC-2 framing).
• select-ui · radio-ui · field-ui — primitives composed here.