Start with the format the parser actually supports
The current importer accepts CSV, XLS, and XLSX. It reads the first worksheet of an Excel workbook. CSV input uses semicolon-separated rows and is decoded as Latin-1 for compatibility with the current source files. Files outside these assumptions should be converted or handled in an agreed migration rather than described as natively supported.
The limits protect the review workflow: 8 MB per file, 2,000 contact rows, 80 columns per row, and 2,000 characters per cell. A larger or more relational source should be split and mapped deliberately. Rows without usable contact fields do not create contacts; they are skipped during parsing. Filename-based market inference exists for a small set of legacy country names, but it is safer to include an explicit market column and verify the preview.
| Input rule | Current behavior |
|---|---|
| Formats | CSV, XLS, or XLSX |
| Excel worksheet | First worksheet only |
| CSV convention | Semicolon separator; Latin-1 decoding |
| Maximum file size | 8 MB |
| Maximum contact rows | 2,000 |
| Maximum columns | 80 per row |
| Maximum cell length | 2,000 characters |
Map the fields, then read the warnings
Recognized aliases cover a combined name or split first and last names, media or outlet, role, email, markets, languages, topics, tier, source, and notes. English, French, and selected Spanish legacy headers are accepted. Several markets, languages, and topics can be separated by commas, semicolons, slashes, or vertical bars; only recognized controlled values are normalized without warning.
A name is required, except that a row with a media value can become a clearly labeled generic Editorial contact. Invalid source emails are not stored as contact emails: they remain visible as warnings and can be preserved in notes. Unknown market, language, or topic values remain review items. Do not remove them from the source merely to make the preview look clean.
| Source meaning | Example accepted headers |
|---|---|
| Name | name, first name plus last name, nom, prénom plus nom de famille, nombre plus apellido |
| Outlet | media, média, outlet, media outlet, magazine |
| Role | role, rôle, title, fonction, cargo |
| email, e-mail, mail | |
| Segmentation | markets, langues, topics, tier and their recognized aliases |
| Context | source, origine, provenance, notes |
Exact matches and probable matches are different decisions
The preview flags an email repeated inside the file and an email already attached to an existing contact. It also flags a same-name, same-outlet record as a probable match. These are clues, not interchangeable deduplication rules. Two similar names at different outlets may be two people; a generic newsroom address may legitimately serve several editorial roles.
On acceptance, an exact existing email links to the existing contact rather than creating a hidden duplicate. A same-name, same-outlet case can create an open merge candidate for human review. The import flow does not promise that every similarity can be undone later. Keep the source copy, reject or fix blocking rows before acceptance, and resolve merge candidates through the dedicated review workflow.
| Signal | Operator response |
|---|---|
| Same email twice in the import | Inspect both rows and keep one intended record |
| Email already belongs to a contact | Confirm the existing relationship should receive the imported context |
| Same name and same outlet | Review as a probable match; do not treat the name alone as identity |
| Invalid email | Correct from a verified source or keep the warning; it is not stored as sendable |
| Unknown controlled value | Map deliberately or leave it unresolved for the migration review |
Reconcile the fictional twelve-row file
The first Solstice preview contains twelve populated source contact rows. One row needs a name or a deliberate generic-media decision, one address is invalid but the row can remain reviewable, and two rows share an exact email. Two contacts with the same name work at different outlets and remain separate. The point of the example is not to produce a perfect acceptance count in advance. It is to explain every difference between source rows, ready rows, ignored rows, created contacts, linked contacts, and merge candidates.
After acceptance, sample the imported records rather than trusting the total alone. Open a contact with several topics, one with an outlet, the exact-email link, and the probable duplicate. Check that notes and relational markets, languages, and topics arrived where expected. The accepted session records created, linked, ignored, and merge-candidate counts for reconciliation.
Use the founding beta for an agreed migration
Founding customers receive help with an initial migration as part of the paid beta. Before any processing, the founder and customer agree the exports, record types, volume, relationships, sensitive handling, and unsupported fields. The customer reviews the import preview and counts before acceptance in a private per-user workspace.
Migration help does not authorize a public upload, an external AI chat, or direct database changes outside the validated app flow. If the source includes custom objects or several client partitions, the workable first scope may be smaller. The beta has no shared seats or multi-client permission model, and email sending remains in Outlook or the customer's existing tool.