Migrate from Henry Schein One to Salesforce Sales Cloud

Patients without an active treatment plan route to Salesforce Lead. Patients with an open treatment plan route to Salesforce Contact and are attached to a DSO Account representing their primary practice location. The split preserves the patient record while keeping Salesforce's Lead/Contact distinction meaningful for follow-up and recall workflows.

Providers are stored as Contacts with a custom Provider_Type__c pick-list field set to 'Dentist', 'Hygienist', 'Oral Surgeon', or 'Office Manager'. Provider NPI numbers migrate to NPI__c custom field. Provider scheduling associations are preserved as a many-to-one relationship via the Provider__c lookup on the Event object.

Each appointment maps to a Salesforce Event. StartDateTime and EndDateTime carry the original appointment time. Custom fields capture the Operatory__c, Appointment_Status__c, and Procedure_Code__c (CDT code) for each slot. Completed appointments with clinical notes carry the note content in the Description field and a custom Clinical_Note__c long-text area.

Treatment plans have no Salesforce standard equivalent. We create a Treatment_Plan__c custom object linked to Contact via a lookup. The object stores proposed CDT codes, estimated fees, accepted flag, and treatment plan date. Each line item of the plan is a Treatment_Plan_Line__c custom object related to the parent plan.

Clinical procedures (CDT codes) and their associated fees, adjustments, and insurance payments become Procedure__c records linked to the Contact. Each procedure record stores the CDT_Code__c, Description__c, Fee__c, Insurance_Paid__c, Patient_Paid__c, Adjustment__c, and Procedure_Date__c. The full procedure history constitutes the migrated ledger.

Insurance carriers map to Salesforce Account records (type = 'Insurance Carrier'). Individual employer-sponsored plans are stored in a custom Insurance_Plan__c object linked to the carrier Account, storing group number, subscriber ID format, and coverage percentages per procedure category. Patient-level coverage assignments are tracked via Insurance_Coverage__c custom fields on the Contact.

Recall intervals (e.g., '6-month hygiene recall') migrate as Salesforce Tasks with a custom Recall_Type__c pick-list and a custom Recall_Due_Date__c field. Tasks are related to the Contact and assigned to the Provider for the recall. FlitStack does not rebuild the automated recall reminders in Salesforce Flow — those are documented for your admin to configure post-migration.

Short clinical notes migrate as Salesforce Notes. Perio chart data (probing depths, recession values) has no Salesforce standard — we create a Clinical_Note__c custom object with long-text area fields for perio data, procedure notes, and medical-conditions flags. The data is preserved for reference but not structured for reporting.

Images and attachments are downloaded from the Dentrix file store and re-uploaded as Salesforce Files linked to the associated Contact or Procedure record. Dentrix's proprietary image file-naming encoding requires a file reference map to ensure images link to the correct patient. The 25MB per-file Salesforce limit applies; oversized files are flagged for manual handling.

Each physical practice location maps to a Salesforce Account (type = 'Dental Practice'). Multi-location DSO accounts use a parent Account hierarchy (ParentId) to reflect corporate structure. Provider and patient counts per location are stored in custom fields on the Account for reporting.

Every migrated record carries its original Dentrix record ID in Source_System_ID__c (text field, external ID). This enables delta-run de-duplication, rollback targeting, and cross-referencing in the FlitStack audit log. No Salesforce standard field is overwritten with source IDs — CreatedDate and LastModifiedDate reflect migration timestamps.

Appointment reminders and automated recall sequences are built-in Dentrix workflows. Salesforce Flow handles these use cases but requires a fresh build. FlitStack exports the Dentrix workflow definitions as a reference document for your admin to configure post-migration. The data supporting those workflows — recall dates, appointment history — does migrate.