Switching from another CRM

Run Smileline alongside your old CRM, then import its history without duplicating the leads that already reached Smileline.

By the end of this page you'll know how to run Smileline next to your old CRM, what to export at switch-over, and exactly what the import does to leads Smileline already has.

Run both side by side

Connect your lead sources to Smileline — website forms, lead ads, call tracking — while your team keeps working in the old CRM. Smileline creates a journey and a New · Call now card on Today for every lead that arrives. That's expected: the import at switch-over updates those leads rather than adding them twice.

Choose one system to report ad conversions while both run. If Smileline and the old CRM both report the same leads, Google, Meta and TikTok count them twice. Conversion feedback switches on by default when you connect an ad account, so either turn off its Conversion tracking in Smileline until switch-over, or stop the old CRM's uploads now.

Switch over in this order

Send new leads to Smileline only

Stop anything that still forwards leads into the old CRM.

Stop working in the old CRM

Ask your team to stop working leads there, and note the time.

Export straight away

Export every lead, following What to export.

Import straight away

Go to Settings → Import & export → Import data and pick your old CRM's preset, or Other CRM / CSV. Run the check, read it (see Read the check first), then import. Pick a time when the front desk is quiet — see While the import runs.

Hand ad conversions to Smileline

Within the hour, turn off the old CRM's conversion uploads. If you turned off Conversion tracking in Smileline, turn it back on.

Review held matches

Rows that look like an existing patient but don't agree strongly enough wait under Needs review. See Review held matches in bulk.

What to export

One row per lead, with a first name and an email address or mobile number. Then, for the import to recognise leads Smileline already has:

Created date — when this enquiry arrived. Some CRMs fold a repeat enquiry into the person's original lead and keep the original date. From those, export the date of the latest enquiry instead.
External ID — the old CRM's id for each lead. A later file or a re-run with the same id updates the same records. DenGro's Unique ID maps to it automatically.
Journey ID — the deal's own id, when one person can have several deals (some CRMs call them opportunities). Map it from your first import onward. A later file can't match deals an earlier file brought in without one, so it adds those deals again as new journeys.

Also export whatever you have of the journey status, stage, lost reason, first-contact dates, values, treatment and attribution.

Without a created date, the import can't recognise a lead Smileline already has by its date, and the mapping step warns you. Rows then only match by id.

Leads already in Smileline

Each row settles one deal for one person, on the board you import into. For a person Smileline already has, the import looks for that deal among their journeys on that board:

By id. A deal an earlier import brought in under the same id (see Import a second file later) goes to that same journey, whatever its date.
By date. Otherwise, a Smileline lead for the same person on the same board, created up to 2 days before or after the row's Created date (and before you uploaded the file), is the same enquiry.

What happens next depends on whether anyone worked the lead in Smileline:

Nobody has worked it — the lead is updated, not duplicated. It takes the file's stage, status, dates and values. A lead matched by date has to be untouched as well; see below.
Otherwise — it's left exactly as it is. The file never overwrites work done in Smileline.
No match — the row becomes a new journey.

The 2-day rule is a judgement, not proof. Two genuinely separate enquiries from one person within 2 days of each other are treated as one.

What counts as worked in Smileline

A lead counts as worked once someone on your team has changed it, logged an outcome on it, worked one of its tasks or booked an appointment linked to it.

A lead matched by date is only updated when it's untouched: it arrived live (for example from a form, a lead ad or a call), it's still open with no first contact recorded, nobody has worked it, and no import has updated it before.

Worked is decided on a best-effort basis from the lead's own history and the tasks and appointments linked to it now. A task that was moved to a different lead no longer counts. A booking made at the very moment the import reaches that lead can be missed.

When more than one lead could match

A person with two untouched leads in the window. The import updates the one holding the New · Call now card, or else the one created closest to the row's date. The other stays exactly as it is, including its card, its sequences and its AI calling.
Two rows for one person within 2 days of each other, without Journey IDs of their own. They're one enquiry: the first row decides the journey and the later row leaves it as it is. Rows further apart become separate journeys.
One id on several rows of the same file. The later rows are reported as errors: "The same id is used for two deals — map a Journey ID column". Put just those rows in a new file with a Journey ID column and import it.
An id another import still holds. While an earlier import is still open (waiting in review, or failed and not cancelled), rows that name the same deals are reported as errors: "Another import that is still open (in review or failed) holds this record — finish or cancel it, then import this file again". Finish reviewing or cancel the earlier import, then upload the file again.
An id that belongs to someone else. When an id points to a different person or board in Smileline, the row is reported as an error instead of being imported.
A Journey ID Smileline hasn't seen. It never updates a different deal. It takes over an untouched live lead from the same enquiry, or starts a new journey.

Cards and enquiries the old CRM already worked

A row counts as worked in the old CRM when it's won or lost, has a first-contact date, or sits in any stage after your board's first stage. When the import updates the lead or adds its journey from such a row, it tidies up Today quietly:

The lead's New · Call now card closes. It's cancelled with no outcome, so nobody is recorded as having called.
A website enquiry from the same person, waiting for triage within 2 days of the row's date, becomes a lead with the imported journey.
A lead-form task for a known patient within 2 days of the row's date closes.
The lead's sequences stop, and it's taken out of AI calling, as if your team had picked it up.

An untouched row (blank status, first stage, no contact dates) changes no card. The lead stays in New · Call now for your team, and a waiting enquiry stays for triage. Cards and enquiries more than 2 days from the row's date belong to a different enquiry and are never touched.

Rows with no status

Some leads in an export have no status at all. Decide what they mean before you export:

Leave status and stage blank — the row counts as untouched. A matching Smileline lead keeps its card, and a new journey opens in your board's first stage.
Set status to Lost with a lost reason — the lead is closed as not proceeding.
Set an open stage after the first one (for example "Contacted") — the lead counts as handled and stays open.

The check shows the effect before anything is written.

Follow-ups for open leads

The board and stages step has a follow-up option, off by default. Turn it on and every imported lead that stays open gets one task, "Call" plus the patient's name, due straight away and assigned to the journey's owner. Its note says which file it came from. It appears with Today's other due tasks, never in New · Call now.

A lead gets no follow-up when:

it's going ahead or not proceeding;
it already has an open task;
the person still has an open New · Call now card, which is already the work;
an import has created a follow-up for that journey before. Re-running the file or importing a second one never adds another, even after your team completes the first.

Read the check first

The check reads every row without writing anything. Next to the new, updated, to-review and error counts, it shows how many leads are already in Smileline and will be updated rather than duplicated, how many are left as they are, how many new journeys it will add, how many New · Call now cards and enquiries will close, and how many follow-ups the follow-up option would add.

If the number already in Smileline is far below the number of leads that arrived while both systems ran, don't import. The board is probably wrong, or the created date is missing or holds when the lead was first created instead of the latest enquiry. Fix it and run the check again.

The check can't foresee repeats inside the same file. A person who appears twice within 2 days shows as two new journeys, but the import treats them as one enquiry. One id used for several deals shows as left as it is, but the import reports those rows as errors. The job's counts after the import are the final word.

Review held matches in bulk

A row whose contact details match an existing patient, without enough else agreeing, is held for review. The review sheet groups held rows by what matched and how strongly, and shows the existing patient's date of birth next to each one.

Merge all and Import all as new resolve a whole group after you confirm. A row that fails doesn't stop the rest. Failed rows are listed afterwards with Retry failed.
A group whose dates of birth differ is marked DOB differs and can't be resolved in bulk. Review those rows one at a time; you can still merge one yourself.
Merging a held row follows the same rules as the rest of the import: it updates the matching Smileline lead, or adds the journey.

Import a second file later

Same preset, same id column. Journeys nobody has worked in Smileline take the new file's state. Leads your team has worked stay as they are. Patient details only fill blanks.
Ids carry across files only under a preset, such as DenGro. Under Other CRM / CSV, a file's ids are recognised only inside that file. A different CSV matches by person and created date instead, and leaves leads an earlier import brought in as they are.
A later CSV with a Journey ID column can't recognise deals an earlier CSV imported, so it adds them again as new journeys. Leave those rows out of the later file.
Boxly exports have no id. A later Boxly file matches by person and created date and leaves leads already imported as they are.

Uploading the same leads file again adds no journeys, follow-ups, cards or notes. Consent evidence may be recorded again.

What never happens

An import never:

sends a text, WhatsApp message or email, or starts a sequence;
places an AI call;
reports an ad conversion;
sends an outbound webhook;
sends a notification;
records that someone called — the lead's activity shows one line saying the import updated it;
overwrites work your team did in Smileline;
brings back an archived journey.

Limits

One board per import. Split the export if leads belong on different boards.
No bulk undo. Read the check before importing. Cancel stops a running import at its next batch, and rows already written stay.
Closed dates. A lead imported as not proceeding (Lost in the file) is dated closed on its created date. A lead imported as going ahead (Won) uses its treatment start date when the file has one, or else its created date. A later file that leaves the lead closed, without a date, keeps its closed date.

While the import runs

When the import and your team change the same lead at the same moment, the import steps back and retries. Even so, while it works through a lead:

an action on that lead in Today may briefly ask you to try again;
a journey you have open may say "This journey was changed by someone else. We loaded the latest version — review it, then try again." Check the latest version and save again, or refresh the page.

Everything else about running, cancelling and resuming an import is in Import & export.

Switching from another CRM

On this page