Workflow improvement
CSV imports need a quarantine lane before they update your CRM
A safe import can receive a file while holding individual rows out of the live system. Parsing answers whether a row can be read. Validation answers whether its contents fit the business rules. Matching answers which existing record, if any, it refers to. Applying the change is a further decision. Treating all four as a single Upload button conceals the place where mistakes enter.
The answer: accept the file without accepting every row
A safe import can receive a file while holding individual rows out of the live system. Parsing answers whether a row can be read. Validation answers whether its contents fit the business rules. Matching answers which existing record, if any, it refers to. Applying the change is a further decision. Treating all four as a single Upload button conceals the place where mistakes enter.
In an illustrative distributor workflow, a salesperson uploads customer records. One customer number has lost a leading zero, one country field contains an internal sales region and two companies share a trading name. A file can be valid CSV while all three situations still require a decision.
A format standard does not define your business meaning
RFC 4180 documents a common CSV format, including how quoted fields can contain commas and line breaks. It does not tell your application whether a blank means unknown, unchanged or intentionally cleared. Nor does it establish whether a customer identifier should be interpreted as a number. Those meanings belong in an explicit import contract.
Document the column names, required fields, encoding, identifier treatment, null behavior and accepted values. Provide a small example file with realistic edge cases. Version the contract when a changed meaning would alter records. A template can reduce variation, but it cannot replace validation of the file actually received.
Make the quarantine lane useful
Store a protected original and assign an import identifier. Keep row identity and a concise reason for each held row: missing account key, unknown product code, ambiguous customer match or invalid date. Give a named business owner a correction route. Avoid a download of rejected rows with no explanation of what to fix.
For ambiguous matches, show enough permitted context to make a decision, without exposing unnecessary personal information. Do not silently merge records because their names look similar. A proposed correction should be traceable to the original value and the person or approved rule that changed it. This is a proposed workflow design, not a claim about a deployed Quarro system.
Define what partial success means before launch
Some imports can apply valid rows independently. Others contain dependent records that must be accepted together. Decide which model fits the process before implementing 'skip errors.' PostgreSQL's COPY documentation, for example, distinguishes failure and error-handling options; the existence of a permissive option does not establish that partial acceptance is right for your business.
Report received, parsed, held, applied and failed states with clear definitions. Make the same-file retry behavior explicit. If staff correct only held rows and submit again, the application should not quietly duplicate previously applied records. Link the retry to the import record and retain unresolved work until someone has addressed it.
Test the exceptions, not only a clean sample
Build a small fixture with quoted commas, line breaks, leading-zero identifiers, blanks, unknown codes, repeated records and a row that fails during application. Check the expected destination of each row and whether the reviewer can complete its correction. Keep fixtures free of real customer data.
A useful first milestone is not a large import volume. It is a reproducible result in which every exceptional row has an understandable status and a responsible next action. Once that behavior is reliable, performance testing can measure how it holds up at the required scale.