Carrying data over from an old CRM, loading lists from spreadsheets, exporting for reporting and editing many records at once — all of it is arranged so that an accidental mistake does not cost you the base. Every such operation has a preview, every one has an undo, and all of them are gathered in one Operations list.
CSV import
The main way to carry data over is a plain spreadsheet file (the CSV format: lines of text separated by commas or semicolons; any spreadsheet program saves it). The product detects the encoding and the separator itself — including Excel files with a semicolon separator and localized headers: column names are recognized in English and in Russian alike.
Then you explain which column matches which field. The agent proposes the mapping itself, recognizing the familiar names, and you check it. For dates you can name their format (for example, “dd.mm.yyyy”), and the values are normalized: phones to one format, dates to an unambiguous form. A row with a wrong INN will not get into the base — it lands in the error file with its row number.
There are ready mapping sets too: if you upload similar files regularly, the mapping can be saved and reused instead of assigning it from scratch every time.
The dry run
Before writing anything, the upload runs “dry”: the product walks all the rows and shows what will come out — how many records will be created, how many turn out to be duplicates, how many rows hold errors. Nothing goes into the base meanwhile.
The error report is not a dry number but a list: row number, column, value and reason. The first two hundred rows are visible right on the screen; the rest are exported as a file that is convenient to correct in a spreadsheet and upload again. This way the very first upload turns into understandable error handling, not into the riddle “why did part of the data not land”.
Import rollback
Even after a successful upload you keep the right to change your mind: a finished run can be rolled back within 7 days. The created records go into the trash, and the changed ones get their former values back — the product saved them for the duration of the run. If somebody corrected a record between the upload and the rollback, that correction is not wiped: it stays, and you are told about it. After the term a rollback attempt honestly answers that the time is past, and names the term.
Related import
Often a clients spreadsheet has a “Company” column. Uploading the company as a separate file and then linking by hand is extra work, so the product can link the data right during the upload: it creates or finds the needed company and attaches the contacts to it. The lookup order is sensible: first by the site domain, then by INN, then by exact name — matching by the name alone is unsafe, because there are many companies with the same names.
What happens when the needed company is not found is your choice: count the row as an error, create the company from the file’s data, or upload the contact without a company. Ownerless records do not appear “quietly” — if a contact stayed without a company, that becomes a separate counter in the report, not a loss. Companies in an upload can also refer to a parent structure — the hierarchy builds itself, and closed circles are rejected.
Export and downloads
Any selected set can be exported: all contacts, a filtered selection, client equipment, the shipping history — anything the product can show. The filters are the same as in the lists, so “export what is on the screen” works without extra effort.
The export file is polite to spreadsheet programs: the right encoding, a matching separator, and values starting with an equals or a plus sign are escaped — so Excel does not take text for a formula. The column headers match the field names, so such an export can later be uploaded back, and the columns will map themselves.
The ready file is available for 24 hours, then it has to be built again — this protects the server from quietly accumulating exports full of personal data. The export history (who exported what and when) stays forever.
Bulk operations
Sometimes many records need editing at once: set the owner, add a label, change the status, archive, delete. This is done by a bulk operation — one command to the agent over a selected list. The action set is understandable: change a field, assign an owner, add or remove labels, change the status, archive or restore from the archive, delete, restore from the trash.
Bulk editing is careful for several reasons. First: before the start there is a preview — how many records fall under it and where it can stumble. Second: errors do not cancel the whole job — a wrong value for one record goes into the error list, while the other records update. Third: the set of records is frozen at the moment of the start, so new records that happen to match the conditions do not get into it. Fourth: each actor has only one bulk edit running at a time — so things do not get tangled.
Bulk-operation rollback
Every bulk edit can be cancelled within 7 days. The product saved the former values in advance, so the rollback puts everything back: fields to their former values, labels removed or returned, deleted records — out of the trash together with their links. If during that time a record was deleted for good or merged with another, the rollback will not break someone else’s work: it will honestly list what it left as is and warn about it.
One reservation: restoring from the trash cannot be undone — that is not a rollback but a new action. A repeated rollback of the same operation is not executed either.
Operations history
All the big jobs are gathered in one Operations section: uploads and downloads, bulk edits, record merges, duplicate searches, mail synchronization. The records run from new to old, they can be filtered by kind, and every operation has a detailed report: how many records were touched, where the errors are, what can be rolled back and until when. While an operation runs, the progress is visible on the screen — no page refresh needed.
The rollback shows its term: while the window is open, a ready phrase for the agent sits next to it; after — an honest note that the window is closed. So it is always clear whether what you are looking at can still be cancelled.
Limits
The sizes and volumes are named plainly, so there are no surprises on a big file or a big base:
- The upload file — no more than 100 megabytes and no more than 200,000 rows. Excel files (the XLSX format) are deliberately not accepted: convert the spreadsheet to CSV — the spreadsheet program does it in one step.
- The work goes in batches — 500 rows per pass, so a big upload does not bring the server down but runs for a while with visible progress.
- An export file lives 24 hours, then the download answers that the term has expired and offers to build the file again.
- Rollbacks are time-limited: import and bulk edits — 7 days, record merges — 30 days, normalization — 7 days.
- One run at a time — each actor has only one bulk edit running at a time.
These limits are not shortcomings but an honest boundary of the possible: the product prefers to refuse clearly over doing the work halfway.