Validate the structure and business meaning of imported data before applying changes. Show users what will be accepted, rejected, or require review.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Define an import contract
Specify required columns, accepted values, identity fields, and whether a row creates or updates a record. Give users a sample file and explain how blank cells are interpreted. A blank might mean no change or clear the value; confusing those meanings can damage existing records.
Separate preview from application
Provide a validation result before committing a large import when the workflow requires review. Report row-level problems with enough context to correct them. Avoid a generic failure message that forces users to locate a bad record by repeatedly editing the file.
Choose a failure policy
Decide whether valid rows can proceed when other rows fail or whether the whole file must pass. Make the result explicit and preserve the import identifier. Users must know which records changed before attempting another submission, otherwise a partial success can become duplicate or conflicting work.
Test repeatability
Import the same file twice under the agreed policy, then submit a corrected version. Verify that the outcomes match the documented create and update rules. Keep a summary of accepted and rejected records so staff can reconcile the import with the source rather than trusting a single completed message.