Partial Failure
Report operations where some items succeed and some fail, so users know exactly what happened and what to do about the rest.
6 states5 edge casesDesktop + Mobile
01The problem
Batch operations — bulk updates, imports, sends, syncs — rarely succeed or fail as a whole. Most interfaces only have two outcomes, success and error, so a run where 18 items worked and 2 didn't is reported as either a misleading success or a frightening failure. Users can't tell what changed, and retrying everything risks applying the successful part twice.
02When to use
Use when
- Bulk actions on many records
- Imports, exports and syncs with external systems
- Sending messages or invites to many recipients
- Multi-file uploads
Avoid when
- The operation is transactional — all items must succeed or none should. Fail atomically and say so.
- Single-item actions; use a normal error state.
03Recommended UX
Statecraft recommendation
Report outcomes per item, lead with both counts in one sentence — “18 invoices approved.
04Desktop behaviour
On desktop, the result stays in context: failed rows remain selected in the table with inline reasons, and a summary bar offers the next step.
Desktop rules
- Summary bar above the table with both counts and actions: Retry failed, Show failed only, Dismiss.
- Failed rows marked with an icon and a short reason in the row itself.
- Group identical reasons: “2 invoices are already paid”.
- Distinguish skipped (nothing to do) from failed (something went wrong).
05Mobile behaviour
On mobile, a toast can't hold a list. Show the headline in a banner and move details to a results sheet.
Mobile rules
3 mobile rules are included in Pro.
Statecraft Pro
Unlock the full pattern
Get the complete interaction flow, states, edge cases, mobile rules and implementation prompt.
- Interaction flow · 5 steps
- 3 mobile rules
- 6 states
- 5 edge cases with recommendations
- 4 microcopy comparisons
- Accessibility notes
- Developer notes
- Claude Code / Codex implementation prompt
Edge cases covered in this pattern
- Many different reasons
- User leaves during a long batch
- Failures that need someone else
- Retry would cause duplicates
- Undo for a partial batch