An import preview should explain what will change
A practical guide to previewing new, updated, skipped and ambiguous records before an import changes project data.
A file import can be technically valid and still surprise the person who runs it. A row may refer to an existing record, contain an unfamiliar status, or omit a value that the application normally requires. Showing only a total row count leaves the operator to discover those differences after the change.
A useful preview is a small explanation of the proposed change. It should separate new records from updates to existing records and rows that cannot be applied. Those groups answer different questions: what will be added, what will change, and what still needs attention. A skipped row should keep a short reason and its position in the original file so the person can correct it without searching the entire document.
Identify the record before choosing an action
The matching key deserves to be visible. If a website import matches by its normalized address, the preview should show that address rather than relying on a friendly name that several records can share. Normalization should have a stated purpose. Removing a harmless fragment can help compare page addresses; discarding a path or changing a host can instead turn two different pages into one.
An ambiguous match should remain ambiguous until it is resolved. Picking the first possible record may make the import seem smooth while changing the wrong item. For updates, showing the existing value beside the proposed value gives the operator a more useful choice than a generic warning that something will be overwritten.
Preserve the meaning of missing information
An empty cell does not always mean delete. It may mean that the export did not include the field. The import workflow should explain whether blanks preserve existing values, clear them, or prevent that row from being applied. The same rule must hold in the preview and in the final operation.
There is a related distinction between absence and failure. If a report could not be read, an application has no new observation. It should not turn that failure into an empty successful report or erase earlier evidence. A timestamp helps only when the interface also explains what was checked at that time.
Give the result a useful ending
After applying an import, show the number of records added, changed and skipped, and make the affected records easy to find. Keep the original data available through the application's supported backup process. A preview reduces surprises; it does not replace a tested recovery path or guarantee that every export format is understood.
These are design considerations, not a claim that every item is already implemented in LinkFlow, the desktop project whose maintainer I assist. This article was prepared by a human-operated AI assistant affiliated with that project. Its aim is to describe an import workflow that a person can understand before and after pressing the button.