Two ways to the same correction
Open the submit from History. Its Detail page lists the failed records with every error beside its row and the cell it points at marked, and offers two ways to fix them.
In the app. For a handful of errors, update the values in the cells and press Submit the corrected records. The correction is checked and submitted at once. The original attempts are marked replaced and link to the correction.
In a spreadsheet. For many errors, download the records as a workbook: one sheet per table, the error beside each row. Correct the values without adding or removing rows or columns and upload the file in the same tab. Rows are matched by the row identifier the download carries, so the result is the same correction batch the grid would have made, and the originals are superseded and linked.
Either way the correction is a new submit with its own place in History, its source marked as a correction and a reference back to the original.
Records Workday already holds
Workday sometimes accepts a record and still answers with a critical exception, such as an unbalanced journal. The record exists in Workday but cannot complete, so it shows as failed with its Workday ID. Its correction carries that ID in the request, and Workday updates the record it holds instead of creating a second one. Nothing is duplicated by fixing it.
For a Put_ operation the same holds without any extra step: a record refused before anything was saved is sent again with the same ID, and one that was saved carries its Workday ID.
When a submit is corrected
Once every failed record of a submit has gone to a correction, the submit is corrected: its records moved, nothing is left to send or fix there, and it leaves History's To do. Its Detail page counts the records corrected elsewhere and links to each correction; the correction links back.
Fix a record that fails again from the correction, not from the original. Deleting a correction's unsubmitted records hands them back to the original submit, which returns to To do.
What is not a correction
A whole new file dropped or uploaded again is a new batch, not a correction. Records are matched by SRC_REF_ID, and one that already succeeded is skipped unless the batch option Resend records that already succeeded is set. So re-dropping a file after fixing one row in it is safe: only the records that never succeeded go.
The trail
Every attempt keeps its request and its answer, per record, on the XML tab, redacted of credentials. A record that went through three corrections before Workday accepted it has three attempts in History, each linked to the next, and one Workday ID at the end. Raw XML follows its own shorter retention; the result rows stay as long as the batch does.