Key Takeaways:
-
The importer is the front door, not a side feature. If it does not work, the portal does not get used.
-
Business teams have to import without IT. Any import that needs a developer becomes a ticket, and a ticket becomes a delay.
-
The preview decides trust. People who can see what will happen before it happens will click. People who have to guess will call.
-
Errors belong on the row, not on the file. "Import failed" is not information. It is a refusal.
-
The data will be dirty, plan for it. 47 % of newly created records contain at least one critical error. An importer built for clean files is built for files that do not exist.
A back office portal stands or falls on its data importer: if a business team cannot load a spreadsheet themselves without involving IT, the portal gets bypassed and the spreadsheet travels by email instead. The five capabilities that decide this are a preview before commit, row-level error messages, repeatable runs, saved field mappings, and a visible history.
We have been building such a back office for some months now, and in that time nearly every discussion about scope has ended up at the importer.
Why the importer decides adoption
A portal usually replaces a collection of spreadsheets, emails and verbal coordination. The switch only works if the new path is less work for the person taking it than the old one. And the first step is always the same: getting existing data in.
If that step depends on a ticket, the comparison is lost. The spreadsheet is local, it works immediately, and nobody has to wait for anyone.
The five capabilities
1. Preview before commit. The file is read, checked and displayed before anything is written. Visible: how many records will be created, how many updated, how many rejected and why. Only then comes the button that actually writes.
This single item has the largest effect. It turns a risky operation into a reviewable decision.
2. Errors per row. Not "import failed", but "row 143: 31.02.2021 is not a valid date", with the option to download the affected rows as a file, fix them and upload again. Anything else forces the business team to hunt through eight thousand rows.
3. Saved field mapping. The same file arrives every month. The mapping from column to field is done once and reused as a template. Without it, every monthly run is a fresh source of error.
4. Repeatability. An import must be able to run again without cleanup. That means a business key per record, so a second run updates rather than duplicates. Without that key, every correction run is a risk.
5. History. Who imported which file when, with what result, and where is the file now? When a value turns out wrong three weeks later, that is the only trail leading to the cause.
What gets underestimated
The CSV format itself. There is a standard, RFC 4180, and almost no tool that fully follows it. The RFC is five pages long and still has to specify what happens with quotes inside quotes, line breaks inside fields, and headers that may or may not be present. Every spreadsheet application answers these questions slightly differently. An importer that assumes one dialect will meet the others.
Character encoding. Spreadsheets, CSV and umlauts are a dependable source of failure. The importer has to detect the encoding and, when unsure, ask rather than guess.
Number and date formats. German and English separators, two-digit years, dates a spreadsheet stored as numbers. This needs detection with a visible statement: "read as a date in DD.MM.YYYY format. Correct?"
Partial success. What happens when eighty percent are valid? Both answers are defensible, but the decision has to be made and visible. Our default is all or nothing, with the option to deliberately accept the valid rows.
Large files. The import must not block a browser session. It runs in the background, with a status display and a notification at the end.
The side effect for migrations
What is built here for day-to-day operation is at the same time the tool for the initial load from a legacy system. A portal that handles spreadsheets cleanly, repeatably and verifiably can also do the first fill. Just with larger files.
Which is why we build the importer deliberately as its own component rather than as an attachment to a form. It is needed in every project, and in every project it decides whether the system actually gets used. If your team still emails spreadsheets around because the portal import "sort of works", we should talk.
Sources
- Shafranovich: RFC 4180 — Common Format and MIME Type for CSV Files, IETF, 2005
- Nagle, Redman, Sammon: Only 3% of Companies' Data Meets Basic Quality Standards, Harvard Business Review, September 2017