CRM Import Without Guesswork: Column Mapping, a Dry Run and a One-Click Rollback
The first week with a new CRM usually starts with a spreadsheet. A firm leaves another system, exports eight hundred rows — customers, articles, stock — and wants them inside by Monday. The tempting shortcut is to hand the file to an assistant and let the model sort it out. That is where most migrations quietly break: a model can rename a column, but it cannot know whether the number in column F is a purchase price or a selling price.
Firmspace treats the import as its own step, not as a conversation. The wizard understands five kinds of data: products, contacts, companies, stock balances and specifications (BOMs). Each kind has its own list of fields with labels, required marks and validation rules, and the wizard only offers the kinds your role may work with: contacts and companies belong to the CRM section, products, stock and specifications to finance.
The file itself is read tolerantly. Excel writes semicolons, Google Sheets commas, 1C tabs; some files start with a byte-order mark that would otherwise glue itself to the first column name. Quoted values, doubled quotes and line breaks inside a quoted cell are handled, and the delimiter is detected from the first line. The goal is not to satisfy a standard on paper but to not lose a data row: a dropped row in a catalog is a product nobody can sell.
Column names arrive in four languages and in the spelling of whatever program produced them. So the wizard keeps a vocabulary of aliases for every field — name, sku, артикул, bezeichnung, штрихкод, sale price, ціна продажу, verkaufspreis — and matches the file header against it. An exact match beats a partial one, and among partial matches the longest alias wins. That detail is not academic: the sale price also answers to the short alias ціна, so without the rule a column called Ціна закупівлі (purchase price) would land on the sale price, and the firm would quietly sell at cost.
What the wizard does not do is guess a field that is not in its vocabulary. Unmatched columns are listed as unknown, required fields are marked as such, and the import refuses to start while a required field has no column. An error before anything is written is cheaper than a correction afterwards.
Before a single record is created, the file goes through a dry run. The preview counts rows over the whole file, not over the page you can see: the table shows the first two hundred rows and says so explicitly. Every rejected row points to its line number and to the exact field that failed — a required value missing, an amount that is not a number, a tax rate out of range, an impossible date, a broken e-mail, phone or URL. Amounts and dates are normalised before the check, so 1.234,56 and a date written as 14.03.2026 are not errors.
The import writes only the rows that passed. The report afterwards is boring on purpose: total, created, updated, skipped, failed, and a log line for each row with the same numbers as in the file, up to a thousand lines. You can fix three cells in Excel, upload the same file again and see exactly what changed.
Re-importing does not double the base. Products are matched by SKU and then by name, contacts by e-mail, then phone, then name, companies by their registration code and then by name. A row that matches an existing record updates it instead of creating a twin. The honest caveat: if a file carries no keys at all, matching by name can merge two different people who happen to share a name — which is why the first thing worth cleaning in any export is the identifier, not the address.
Stock balances are where a naive import does real damage, because a number written over an existing balance erases the history behind it. Here a quantity in the file never edits the balance directly: it becomes a receipt movement with the note Import, and the stock journal stays immutable. If the import was a mistake, the journal still knows what happened, and there is a counter-movement to answer it.
Specifications are read row by row, one row per component, and grouped by product. A product that was already specified is not overwritten: the import creates the next version, and production orders that were planned on the old version keep their own numbers. If a component is missing from the catalog, those rows fail with a plain instruction — import the catalog first — instead of inventing a product.
Every run becomes a batch with a number, and the last twenty are visible in the same window. One click rolls a batch back: records created by it are deleted, changed fields return to their previous values, and stock movements are cancelled by counter-movements rather than erased. A second rollback of the same batch is refused, and the rollback itself is written to the audit log. That is the difference between an import you can try and an import you have to be sure about.
Files from the same supplier arrive with the same headers every month, so a mapping can be saved as a template for each data kind. The next file opens already mapped; the fifty most recent templates are listed next to the batch history. For a firm that receives a price list every month, that is the difference between a ten-minute routine and a small project.
The wizard lives in Settings, under Import, and it is deliberately not behind a plan limit: moving your own data in is not a paid feature. One request carries up to 4.5 MB, a catalog of five thousand rows is checked in the preview, and a larger file is split rather than silently truncated.
None of this calls a model, and that is the point. An import has to be repeatable: the same file in, the same result out, the same line numbers in the report. The assistant earns its place on the other side of the process — it searches the imported contacts, reads the catalog, adds up the invoices — and it is exactly as good as the data it was given. Which is also why it is not allowed to fill in a price or a tax rate it did not find: missing data stays missing until a person types it.
A practical test before trusting any migration: import ten rows, read the preview, run them, read the report, roll the batch back, and check that the base looks exactly as it did five minutes ago. A system that can undo itself is a system you can hand real customer data to.