Use four result classes
| Result | Meaning | Default next step |
|---|---|---|
| Applied | The named change was confirmed for this record | Inspect or continue |
| Skipped | Policy intentionally prevented an attempt | Resolve eligibility or selection |
| Failed | An attempt returned a specific failure | Correct and retry only if declared safe |
| Unknown | No authoritative terminal result is available | Reconcile by operation and record ID |
Unknown is not the same as failed. A timeout may hide a successful server change, so automatically repeating it can duplicate a non-idempotent effect. The service needs an operation ID, per-record identity, and either idempotency or a way to retrieve the durable result.
Summarize without hiding the records
Lead with the complete count: “5 selected: 2 applied, 1 skipped, 1 failed, 1 unknown.” Link each count to the matching rows in the ledger. Every row should name the record, intended action, result, reason, and allowed next action.
The W3C's status-message guidance covers results and errors that appear without moving focus. Make the whole summary programmatically available; announcing only “2” lacks context. Its error-identification guidance supports text descriptions of failures rather than color-only row treatments.
Keep the ledger available after the initial message. A toast is not enough for an operator who must resolve several records or export an audit trail.
Retry a named subset, never “everything again” by default
Eligibility belongs on each result. A validation failure may become retryable after correction. A locked record may be skipped until its review completes. An unknown result requires reconciliation before retry. Applied rows should not be selected again unless the action is explicitly idempotent and the product owner has chosen that behavior.
The retry review should state the number and identities selected, exclude all other outcomes, and recheck current permission and record version.
Acceptance checks
- The summary totals equal the original selected count.
- Applied, skipped, failed, and unknown remain distinct.
- Every row names its result, reason, and next action.
- The complete summary is a programmatic status message.
- Color and icons are not the only result indicators.
- Unknown outcomes cannot be automatically retried.
- Retry names its exact subset and excludes already applied records.
- Results remain retrievable long enough to reconcile the operation.
These checks do not implement transaction boundaries, idempotency, durable job storage, or authorization. They expose the information those backend contracts must provide.