A clean CSV can still be the wrong update. A blank cell might erase a useful note. A repeated product code might create a second record. A product missing from the file might be mistaken for a deletion.
This Part 4 exercise helps you test an app you are building in Overskill. Compare five existing catalog records with a proposed change file, then leave with an exact change plan and a decision to hold or test it. All products and prices are fictional. Nothing here imports data or demonstrates the behavior of your app's importer.
Download the filled and blank review worksheet. It links every sample file and the complete answer key. If your source rows still need cleanup or identity rules, start with the spreadsheet mapping guide.
Put the existing value beside the proposed value
The existing catalog contains P01 through P05. Prices are stored in invented USD cents. The incoming file has six rows and an explicit action for each one: update an existing SKU with PATCH, or add a new SKU with CREATE.
For this exercise, an update may change only the price and customer-facing note. An empty patch price means keep the current price. A note needs an explicit instruction: keep, set or clear. These are proposed rules for this fictional workflow, not native import defaults.
Scroll horizontally to compare all columns.
| Record | Before | Proposed result | What must stay |
|---|---|---|---|
| P01, Clip pack | Price 500; note “Box of 10” | Price 550 | Name, note and internal note “Count packs each Friday” |
| P02, Paper roll | Price 1200; note “White” | Keep 1200; clear the note | Name and internal note “Stockroom shelf B” |
| P03, Ink bottle | Price 900; note “Blue” | No change | All five fields |
| P06, Pocket notebook | No existing record | Create at 650, note “Pocket size” | New internal note starts empty under this example's policy |
P02 shows why intent matters. Its empty price cell does not mean zero or deletion. The separate clear instruction deliberately empties its note. The existing internal_note column is absent from the incoming file altogether. That field is not available for this file to change: P02's shelf location must survive.
Preserve both the input file and the target snapshot used for the comparison. A plan based on different current values needs a new review.
Hold the whole proposal when a row is unresolved
Two rows prevent this original batch from proceeding:
Scroll horizontally to compare all columns.
| Row | Request | Decision |
|---|---|---|
| R05 | Patch P99 | Hold. P99 does not exist; do not silently turn an update into a new record. |
| R06 | Delete P05 | Hold. This workflow does not allow deletion; retain P05. |
The six rows account for two proposed updates, one proposed creation, one unchanged row and two held rows. Under this exercise's policy, any held row stops the whole proposed change. The starting catalog still has five records; none of the other proposals has been applied.
This is a decision rule, not evidence that a live system can apply or undo a batch atomically. If your app cannot establish what will happen, keep the change on hold.
Check the complete result, including untouched records
The corrected file retains R01–R04. The worksheet records why R05 and R06 were excluded; they have not disappeared from the review history.
Its projected catalog contains six records: P01 and P02 changed, P06 added, and P03, P04 and P05 unchanged. P04 is absent from the incoming file, so it remains. P05 remains because its deletion was rejected. Every original internal note is preserved exactly.
There are three proposed record changes, not four: R03 requests values the record already has. Compare the complete records with the answer key rather than accepting a matching total alone. The row review lists the original and repeated-target decisions.
The corrected plan is suitable for a separately authorized test. It is not permission to load a live catalog, and its projected file is not an export from a running app.
Do not let file order choose between repeated SKUs
The separate repeated-target file asks to set P01's price to 550 in D01 and 560 in D02. Hold both rows and keep the starting price of 500. Choosing the first or last row would hide a decision the operator has not made.
For this exercise, even two identical operations on the same SKU are held. Resolve the repeated target and prepare a new unambiguous file. This is stricter than guessing whether two rows are duplicates; it is a declared rule for changing existing records.
Use the plan in Overskill
Overskill's current import help describes loading through the editor chat as a one-time copy. It says repeated input rows are not merged and missing fields remain empty. Uploading a file with matching SKUs is therefore not evidence that it will update those existing records or follow the patch rules above.
For an existing app, establish its actual loading method and test it with fictional data in an authorized test copy before using a real change file. If a non-writing comparison or matched update cannot be established, stop. Do not use a real import to discover whether it overwrites data.
For a new app, open the brief builder. Use the worksheet's filled audience, outcome and records inputs to request a preview-only catalog change workflow, including operator-only access to source files, internal notes and exports. Edit those inputs for your task, choose the appropriate access boundary and review the generated read-only prompt before selecting Start build. Copy brief remains available as a secondary action.
Supply the fictional files separately after the app exists; the link does not attach them, import records or implement the review policy. Account access and credit requirements still apply when building. Keep live writes out of the first version, then record what an authorized test actually demonstrates beside the worksheet's expected results.