Import & export

By the end of this page you'll know which transfer to use: Core Practice Transfer for a quick Smileline-to-Smileline account migration, or entity CSVs for selective portability and migration from another CRM.

Everything on this page happens under Settings → Import & export. Owners and managers can use entity CSVs. Core Practice Transfer is owner-only.

Move a Smileline practice without a database snapshot

Core Practice Transfer packages the supported CRM relationship graph behind an authenticated API. It does not need direct database access and it does not copy a database snapshot.

The package includes:

• practice display settings, locations, boards and stages
• treatments, lead sources, lost and cancellation reasons, contact methods, tags and referrers
• appointment types, operatories and practitioners
• patients, channel-specific contact preferences and their evidence history
• each patient's chart number, codice fiscale, previous system number and NHS ethnicity code
• each patient's occupation, GP, emergency contact and clinician preference, with each professional contact's kind, so a GP arrives as a GP
• journeys, safe normalized attribution touches and stage history
• tasks, appointments and appointment participants

It deliberately excludes authentication and practice memberships, billing, subscriptions, agreements, conversations, messages, files, audit logs, automations, templates, campaigns, booking and provider operations, payments, credentials, webhooks, PMS state, NHS numbers, Reputation state, referrals, reports, chat, knowledge-base and dialer state. Staff references are matched to existing destination members by exact email; unmatched staff assignments become unassigned.

A codice fiscale, previous system number or ethnicity code that doesn't fit the destination — not a valid value, already held by another patient there, or an ethnicity code the NHS list doesn't know — is never dropped: the patient is still imported, and the value is added as a line in the patient's note saying why it wasn't recorded.

Before you start

Create the destination as a new, otherwise unused Smileline practice. Complete onboarding with the same legal country and accounting currency as the source, but do not change the generated CRM configuration or connect integrations. The source and destination must be different practices.

The unused built-in email channel created during onboarding is allowed and stays in place during the transfer. A configured sender, connected mailbox, sending domain or existing inbox contact makes the destination ineligible.

Export and import

Import from DenGro or Boxly

Both platforms get a one-click path: their export columns are recognised automatically, so you skip straight to choosing a board.

Moving over from a CRM you ran alongside Smileline? Read Switching from another CRM first. Leads that already reached Smileline are updated, not duplicated, and the page explains when.

A DenGro row brings the whole picture across: the patient's details, their journey (stage, status, potential value, lost reason), marketing consent with its original date, and the attribution trail — channel, source, UTMs and click ids all land on the lead's touch history. Consent is recorded separately for every populated, unblocked contact channel, so SMS, WhatsApp and email remain independently auditable.

Import from any other CRM

Choose Other CRM / CSV instead. You'll additionally pick what the file contains:

• Leads (patients + journeys) — one row per lead, the shape most CRMs export
• Patients — demographics and contact details only
• Journeys, Appointments, Tasks — child records matched to existing patients by email or phone
• Vocabularies — treatments, tags, lead sources and the other settings lists

The mapping step recognises common column names ("Surname", "DOB", "Postcode"…) and shows sample values next to each column so you can verify the guess. Every row needs at least a first name and an email address or mobile number.

For leads, map a Created date column: without one, the import can't recognise a lead Smileline already has by its date, and the mapping step warns you. A tags cell can separate tags with ;, , or |, or hold a list in square brackets such as ["VIP","Implants"].

An appointments file can map a Booked on column: when the booking was made in the other system. The dashboard counts an imported appointment as a booking on that date. The mapping step picks a column named "Booked at", "Booked on" or "Date booked" for it. It picks a created-date column ("Created at", "Date created") instead only when the file has no booked column, so a blank booked cell stays blank rather than taking the created date. An appointment imported without a booked date still imports, but isn't counted as a booking — the day you imported it is not the day anyone booked it.

Dates and phone numbers vary by platform, so the values step has two dials: the date format (detect, day-first, month-first or ISO) and the default country for phone numbers without a prefix.

Money values must use the practice's locked currency. A matching EUR, GBP or USD code, or €, £ or $ symbol, is accepted; a different or unsupported currency is reported as a row error rather than converted. Amounts must be zero or positive; negative or implausibly large values are reported as row errors rather than imported.

Codice fiscale and previous system numbers

A patients or leads file can bring two identity numbers:

• Codice fiscale — the patient's Italian codice fiscale, for an Italian practice. A column holding a UK National Insurance number is not picked for it.
• Previous system no. — the number your old system gave the patient. The mapping step picks it for a column named "Chart number", "Chart no", "Patient number", "Record number" or "Numero cartella". It is kept beside the chart number Smileline gives each patient, never in its place, and searching for it finds the patient.

A value that doesn't fit is never dropped. When a codice fiscale isn't 16 letters and digits once its spaces are removed, another patient already has it, or the practice isn't in Italy, or when a previous system number is longer than 64 characters, the patient is still imported and the value is added as a line in the patient's note saying why it wasn't recorded.

GPs and emergency contacts

A patients or leads file can also bring the clinical record's care contacts:

• Occupation — picked for a column named "Occupation", "Job" or "Profession".
• GP — the GP's name. The values step lists each GP name in the file under Their GPs: match it to a GP in Professional contacts, or leave New GP and the import adds it. A GP whose name matches one you have is picked for you. Map the GP's phone or address columns to Note (appended) if you want to keep them.
• Emergency contact name, Emergency contact relationship and Emergency contact phone — picked for columns such as "Emergency contact", "Next of kin" and "NOK phone". The phone is kept as typed when it can't be read as a number.
• Clinician preference — no preference, female, male or prefers not to say.

The emergency contact is one group: a relationship or a phone needs a name. A row with an emergency phone or relationship but no name still imports; the check says how many rows that is, and those details are written into the patient's note instead.

When a row updates a patient you already have, these fill gaps only, and the emergency contact fills only when the patient has none at all.

A file that can't be read

The file is stored the moment it arrives, before anything reads it. If it can't become an import — it isn't a readable CSV, or Smileline couldn't start the import — you see why at once, and the file is kept under Kept files on this page instead of being thrown away. An upload interrupted before Smileline could open its import or keep it appears there too, within about half an hour; if Smileline couldn't store the file at all, nothing is kept and you're asked to send it again. Retry reads it again and opens its import — one import per file: if the upload had in fact opened one, Retry opens that one, and that file can no longer be discarded. Discard asks why and deletes the file. Only a person can discard a kept file: Smileline never deletes one by itself. A kept file holds whatever the CSV holds, so discard one uploaded by mistake.

How duplicates are handled

When an imported row shares an email address or mobile number with an existing patient:

• Strong agreement (enough else lines up too, for example the same email and mobile plus the full name, or the same email, date of birth and full name) — the row merges into the existing patient automatically. A different date of birth never merges automatically.
• Anything weaker — the row is held for review rather than guessed at. The job shows Needs review; click it to see each held row next to the patient it resembles, with both dates of birth, and choose Merge into existing or Import as new. A group of similar matches can be resolved at once with Merge all or Import all as new, except a group whose dates of birth differ. See Review held matches in bulk.

A held row whose existing patient has since been erased stays in the review, detached from them: it reads Existing: Erased patient, Merge into existing is gone, and Import as new creates it as a new patient. The job's counts don't change.

Patient merges only fill blanks, including a re-run or later file matched by id: nothing you've typed is overwritten, and a note line the patient already has isn't added again. A codice fiscale or previous system number is added only when the patient has none yet. An opt-out in the file is still applied.

A journey is updated only while nobody on your team has worked it in Smileline. For a lead that arrived in Smileline before the import, the same person on the same board within 2 days of the row's created date counts as the same enquiry. Switching from another CRM explains both rules.

When one person can have several deals, map a Journey ID column from your first import. Without one, each person's id stands for a single journey, and a second row with the same id in one file is reported as an error.

Re-uploading the same patients or leads file is safe. A DenGro lead keeps its DenGro id. Other rows are recognised by the file's contents and their id or row number. Either way a second run adds no patients, journeys, cards or notes; consent evidence may be recorded again. A tasks file is not recognised again: importing it twice adds its tasks twice.

A row whose id points to a patient who was erased in Smileline is not imported: it is reported as a row problem, patient erased, so importing an old file again never brings an erased person back.

Ids carry across files only under a preset such as DenGro. A different plain CSV doesn't recognise an earlier file's ids, and Boxly exports have no id, so their rows match leads already imported by person and created date and leave them as they are. A later plain CSV with a Journey ID column can't recognise deals an earlier CSV imported and adds them again, so leave those rows out of it.

Export

The Export section downloads any entity as a CSV that opens straight in Excel or Sheets — patients, journeys, appointments, tasks and every settings vocabulary. Money cells include the locked EUR, GBP or USD code so they cannot be re-imported as another currency. A download holds up to 10,000 rows; anything bigger, patients included, automatically becomes a background job with no row limit and appears under Recent jobs when ready. A big export from the patients list lands here too, with that list's search, filters, sort and columns. One file can hold up to 512 MiB of CSV and one row up to 1 MiB: an export past either stops straight away with a message saying why — for a row, which record — so you can shorten that record or contact support.

The appointments file has a Booked At column after Created At. Booked At is when the appointment was booked: when it was created in Smileline or, for one synced from your practice management system or imported from a file, the booking time that system or file gave. It is blank when that time is unknown. Created At is when the row reached Smileline. Importing the file maps Booked At to Booked on, so every booking keeps its date on the dashboard and one with a blank cell stays uncounted.

A background entity export fixes an upper creation-time boundary when it starts, then walks rows by (created at, id) rather than mutable page offsets; a patients export walks the patients list's own order the same way. Rows created after that boundary belong to the next export, and a redelivered completed job does not rebuild its file. This is a bounded high-water export, not a database snapshot: a row that already existed may contain an edit made before the worker reached it, and a patient whose sorted value (say, its last name) is edited while the export runs can be skipped or appear twice. The default Created order never moves.

While an import runs

Imports run in the background in batches — you can leave the page. The job row under Recent jobs shows live progress, and the counts (created, updated, errors, to review) update as it goes. Cancel stops the job at the next batch; rows already written stay.

If an import fails part-way — an outage, a fault in one batch — the job shows Failed with two buttons. Resume continues from where it stopped, in the same phase (the check or the import itself), without re-running the rows already handled; Cancel closes the job and keeps what was written. Until you resume or cancel it, a failed import keeps the leads it wrote: uploading the same file again reports those rows as held by the open import and imports the rest.

A CSV import, and resolving its held rows, sends no outbound webhooks to your endpoints, and never sends messages, notifications or ad conversions.

While an import works through a lead, an action on that lead in Today may briefly ask you to try again, and a journey you have open may say it was changed by someone else. Check the latest version and save again, or refresh the page. Run big imports when the front desk is quiet.

Every import and export is recorded in Settings → Activity log.

Uploaded CSV files are removed after a terminal job's download/review window. Row-error and possible-match snapshots are redacted 30 days after the job is finished. Unresolved snapshots have a hard 90-day limit, so an abandoned review cannot retain raw patient details indefinitely.