Migrate from Dentally to Salesforce Sales Cloud

Dentally Patient maps to a Salesforce Contact under an Account record. Each unique practice or clinic in Dentally becomes an Account first; Patients without a clinic assignment land under a default 'Unassigned' Account. This two-step pattern (Account → Contact) ensures Salesforce's required AccountId relationship resolves before contacts are created.

Dentally supports custom fields on Patient records (text, tick-box, dropdown). These require Salesforce custom fields on Contact — created with the __c suffix and matching data types. Multi-select pick-lists in Dentally become multi-select pick-lists in Salesforce; text fields become text fields. We create the Salesforce fields first, then map each one during migration.

Dentally Practitioner resolves to a Salesforce User by email match. Name maps to FirstName + LastName; role (Dentist, Hygienist, Receptionist) maps to a custom Title or Role field on the User record. Active/inactive status maps to the IsActive flag. Unmatched practitioners are flagged before migration — your team either invites them to Salesforce first or assigns their records to a fallback owner.

Dentally Appointment maps to a Salesforce Task. The appointment start time maps to ActivityDate; start_time and end_time become custom Time_Start__c and Time_End__c fields. Status maps via value-mapping (Scheduled → Not Started, Completed → Completed, Cancelled → Cancelled). The linked Patient becomes WhoId (Contact lookup); the Practitioner becomes a custom Practitioner__c field since Tasks do not support User as WhatId.

Dentally appointment records may carry treatment_codes, surgery, and recall-type custom fields. These map to custom fields on the Task object (e.g., Treatment_Code__c, Surgery__c, Recall_Type__c). Salesforce Tasks support custom fields natively, so no separate custom object is needed. These custom fields preserve the original treatment codes and location references, allowing reports to filter appointments by surgery or recall type in Salesforce.

Salesforce has no native Invoice object in standard Sales Cloud — invoices from Dentally migrate to a custom Invoice__c object. Fields include invoice_number, invoice_date, total_amount, amount_paid, payment_status, and linked Contact and Account lookups. Payment_status values (Paid, Part Paid, Outstanding, Written Off) require value-mapping to match your Salesforce pick-list.

Dentally Treatment Plans — including the plan name, status, proposed_date, and total_price — migrate to a custom Treatment_Plan__c object linked to the Contact record. This preserves the plan's proposed treatment items and pricing without collapsing them into a note field. Status values (Proposed, Accepted, Declined, Completed) require value-mapping to Salesforce pick-list values.

Individual line items within a Dentally Treatment Plan — fee_per_unit, quantity, discount, total — map to a child Treatment_Item__c custom object under Treatment_Plan__c. This preserves the per-item pricing and item description. Link to the Contact for chair-side reference. The Dentally item code and udi_code fields map to custom text fields on the item.

Dentally multi-site practices (multiple surgeries under one account) map to multiple Salesforce Account records — one per site. For organizations that use Salesforce Territories for multi-location reporting, we deliver a territory-assignment plan as part of the migration package so your Salesforce admin can pre-configure the territory hierarchy before data lands.

Files attached to Dentally Patient records, Treatment Plans, or Invoices are downloaded and re-uploaded to Salesforce as Files (ContentVersion + ContentDocumentLink). Each file is linked to the corresponding Salesforce record by type. Salesforce's 25MB per-file limit applies; larger files are flagged before migration.

Dentally Patient records may store NHS_number (UK) or equivalent national health identifiers. Salesforce Contact has no native NHS number field. We create NHS_Number__c as a custom text field on Contact and map the source value directly. If your practice spans multiple countries, equivalent fields (e.g., Health_ID__c) are created per region.