Migrate from Dentally to Twenty CRM

Dentally Patient maps to Twenty Person — firstname, lastname, email, phone, and address fields translate directly. Clinical fields unique to dentistry (medical_history, alert_notes, band_allocation) require Twenty custom fields on Person. Patient ID is preserved as source_id for de-duplication on re-migration.

Dentally stores address components as separate fields (address_line_1, address_line_2, city, county, postcode). Twenty Person has a structured address field. We concatenate address_line_1 and address_line_2 into a single street value and map city, county, and postcode to their respective address sub-fields.

Dentally clinical fields — band_allocation, medical_history, alert_notes, medical_alerts, recall_date, preferred_provider, first_visit_date, last_visit_date — have no Twenty native equivalent. We create custom fields on Person for each: band_allocation__c as a select, medical_history__c as a long-text area, alert_notes__c as text, recall_date__c as date, preferred_provider__c as a text relation note.

Referring dentist practices stored in Dentally become Twenty Company records. The practice_name field maps to Company.name, and the practice address transforms using the same concatenation logic applied to Patient addresses. Referring dentist contact details — email and phone — become standard Company contact fields. If no explicit referring practice exists, the referral source may be captured as a free-text note on the patient record instead, though this limits ability to consolidate multiple referrals from the same practice.

Dentally TreatmentPlan records do not map to any Twenty standard object. We create a Twenty custom object named TreatmentPlan with fields: procedure_name (text), treatment_date (date), tooth_number (text), quadrant (select), clinical_notes (long-text), estimated_cost (currency), and status (select: Planned, In Progress, Completed). The plan links to the Person record via a relation field.

Dentally allows custom fields on Treatment Items via Settings → Treatments & Plans. Each custom field becomes a custom field on the TreatmentPlan custom object, with type mapping: text fields to text, tick boxes to boolean, preset options to select. We document every custom field name and type during the audit phase before schema creation.

Dentally clinical notes attached to treatment plans have no standard CRM equivalent. We create a Twenty ClinicalNote custom object with: note_date (date), provider (text), tooth_reference (text), note_type (select: Examination, Treatment, Follow-up), and body (long-text). This is linked to both the Person and TreatmentPlan records.

Dentally Appointment records map to Twenty Task objects. appointment_date and appointment_time combine into Task.dueDate. appointment_status maps to Task.status (Planned → Open, Completed → Completed, Cancelled → Cancelled). appointment_type maps to a custom task_type__c field. The Task links to the Person record for the patient. Recall interval data (days_until_recall) is preserved as a custom recall_interval__c field on Person.

Dentally Invoice records (date, amount, status, items) do not exist in Twenty standard objects. We create an Invoice custom object with: invoice_date (date), total_amount (number), status (select: Paid, Outstanding, Overdue), and line_items (long-text storing item descriptions and amounts). Invoice links to the Person record for the patient who received the treatment.

Dentally team members (dentists, receptionists, hygienists) map to Twenty WorkspaceMembers. We match by email address: if a Dentally owner_email exists on a record and a matching WorkspaceMember exists in Twenty, we assign OwnerId. Unmatched owners are flagged before migration and assigned to a fallback user. WorkspaceMembers must exist in Twenty before import runs.

Dentally X-rays, intra-oral photos, and document attachments are stored as blobs in Dentally's file storage. Twenty has no native dental imaging schema and stores files as generic Twenty Files. We export attachments separately via Dentally's file export mechanism and re-upload them as Twenty Files linked to the relevant Person or TreatmentPlan record. No clinical metadata (tooth reference, imaging type) migrates automatically — it must be manually relinked or stored as custom text fields.

Dentally practice-level settings — currency, timezone, and region — are configuration data rather than records and therefore do not migrate as data objects. FlitStack AI manually configures Twenty Workspace settings to match the Dentally practice configuration before any data import begins. Currency symbol and format, timezone, and locale settings are set via Twenty's Settings → Workspace area. This is a configuration step performed by the FlitStack AI team prior to import; it is not a data migration operation and does not involve record-level data transfer. Workspace configuration must be completed before Person and Company records are imported.