Bulk inline feedback must split successes from failures

What it is

Twelve rows checked, then Delete or Share: the twelve rarely share one fate. An item-level result requires successes and failures to show on their own objects, not as a single “partially succeeded.” A summary may exist; it cannot replace the roster. People need to know which rows remain, which have gone, and whether the failures can be tried again. The subject of bulk inline is each member of the set, not the click.

Why it happens

Bulk multiplies one intent across many objects, but failure is almost always an object’s own reason: permission, lock, conflict, already gone. One summary crushes those reasons into a single “partial,” and the next step cannot be chosen—retry-all harms the successes, abandon-all leaves the failures. Item marks reopen the set so the next step can be “handle only the failures.” They also block mis-attribution: ten successes and two failures, if the global tone leans failure, get read as a broken bulk, and people undo the ten that already completed correctly. Separate inline presentation pins success on successful objects and leaves failure on failed ones, so the two endings stop contaminating each other.

Where it stops holding

When the set is too large to see in one viewport, item marks sink below the fold and need a failure roster or a “failures only” filter; otherwise separate presentation is no presentation. When everything succeeded, twelve checkmarks need not flash; one summary plus a weak change on the objects is enough, so success theater is not louder than failure. When everything failed, retry-all should exist, while each row still keeps its own reason, because the reasons may differ. A bulk still in flight should show which items are still going, so “not yet reached” is not read as failed.

Applying it

• At the end of a bulk act, give both a summary (10 of 12 succeeded, 2 failed) and per-object state; failed items should open a failures-only view.
• Keep a reason and a per-item retry on failures; do not let one Retry all overwrite items that already succeeded.
• Do not let success marks occupy a loud rank for long, or they compete with failures.
• Verify by mixing two failures with different reasons among successes. If people cannot name which two and why, item-level result was never done.

Related

• Within the group: E6.13.1 Inline feedback puts the result next to the trigger · E6.13.2 Inline presentation keeps the result tied to the object · E6.13.3 Inline feedback must look unlike ordinary content
• Adjacent: E4.05 Inline and bulk actions · E6.10 Error and fallback pages · E6.01 Toasts
• Search terms: partial success · item-level error · bulk result