When some fields fail to submit, distinguish the success and failure scopes

What it is

In one submit, some fields have already landed on the server and some were rejected (attachment too large, one column failed validation, one service timed out). Distinguishing success and failure scope means the result must list what already took effect, what did not, and whether the next step on the misses is retry or fix-then-send. A blanket “submit failed” makes people send the already-successful parts again, or abandon parts that already took effect because they think nothing did. Item-by-item success in batch operations is another family’s problem. Here it is mixed results at field level on one form. Whole-form success confirmation, wait progress, and next actions on the success page all assume a single outcome.

Why it happens

People treat one click as one atomic transaction. If the server is not transactional but the UI writes atomic failure, the model is wrong. An email change that already took effect, an attachment already uploaded, then “start over” duplicates or conflicts. A second layer: scope needs object names, not status colors. “Avatar updated; résumé upload failed; the application was not sent” is more useful than a page-wide red bar. Failed items need a reason and their own action (replace the file and retry; save the profile and apply later). Successful items should become read-only or marked “saved” so they are not treated as still to edit. If the technology actually rolled the whole form back, say “nothing took effect”; do not look like partial success. A lying scope is worse than no scope.

Studying it

Build a mixed result: profile saved, attachment failed, main record not created. Compare one failure sentence, an itemized list, and leaving already-successful items editable.

Independent variables: itemized versus blanket result, whether successful items stay editable, whether failed items can be retried alone. Dependent variables: resubmits of already-successful parts, abandoning already-successful parts, ability to name what took effect, whether a solo retry hits only the failed channel.

The lab must provide real evidence of “already took effect” (avatar still there after refresh). Do not measure this entry with an atomic whole-form failure—that is not partial failure.

Where it stops holding

A true atomic transaction failure should say nothing took effect; do not invent itemization to look thorough. Payment charged but order not written is money: treat the charge as a successful item and offer query/refund, not as an ordinary field failure. An offline queue with “some enqueued, some rejected by validation” also needs scope; effect happens after reconnect. Screen readers must hear success/failure per item, not only a colored column.

Applying it

• Itemize mixed results: took effect / did not / reason. Items that took effect no longer appear as submittable fields.
• Give failed blocks their own retry or “change only this block and send.” Do not make whole-form submit the only exit.
• If the whole form actually rolled back, the title says nothing took effect; the list must not contain a “saved” row.
• Verify: avatar success, résumé failure; after refresh the avatar remains and the UI says the résumé did not take effect. People must not be led to upload the avatar again. A reader hears both blocks’ states. Show whole-form rollback as “partial success” as a lying-scope control that must be blocked.

Related

• Within the group: H1.16.1 Successful submit needs an explicit confirmation, not a silent redirect · H1.16.2 Long processing needs a progress cue so people do not resubmit · H1.16.3 The result page must name the next actions that can be taken
• Adjacent: H3.13 Handling partial failure · H7.13 Payment failure and unknown state · I3.05 Idempotency and duplicate submit
• Search terms: partial success · mixed result · submit scope