Migrate from My Dental Clinic to Salesforce Sales Cloud

Clinical treatment records require a custom Salesforce object

My Dental Clinic stores tooth charts, procedure codes, and clinical notes as part of the patient record. Salesforce has no native equivalent — treatment history does not map to any standard object. We create a Treatment_Record__c custom object with a Contact lookup, procedure-code pick-list, tooth-number field, and clinical-notes textarea. Your Salesforce admin must create this object before data migration runs, or we deliver a metadata deployment package as part of the migration plan.

Insurance data scattered across patient record needs field consolidation

My Dental Clinic stores insurance carrier, group number, subscriber ID, and benefit percentages as separate fields within the patient record. Salesforce Contacts have no native insurance block. We map these to custom fields on Contact (Insurance_Carrier__c, Group_Number__c, Subscriber_ID__c, Benefits_Notes__c), but the Salesforce admin must create these __c fields in the org before migration. If you use secondary insurance, that data collapses into the Benefits_Notes__c textarea unless you create a separate custom object for insurance tiers.

Billing ledger does not map to Salesforce Opportunities cleanly

My Dental Clinic maintains a full payment ledger per patient — charges, payments, adjustments, and running balance. Salesforce Opportunities track deal stages and amounts, not double-entry accounting. We map the outstanding balance to Opportunity.Amount and store the full payment history as a custom text field (Payment_History__c) and Opportunity history entries. For practices that need GAAP-compliant billing history, Salesforce requires a separate integration with dental billing software such as Rectangle Health or Revenue Well — the ledger data itself is not a native Salesforce object.

Provider-to-User email resolution is required before migration

My Dental Clinic manages providers and staff within a single-practice account. Salesforce requires User records for Activity owners (Event.OwnerId, Task.OwnerId). We resolve providers by email match to existing Salesforce Users. If a provider does not have a Salesforce User account, their records land with a fallback OwnerId or remain unassigned until your admin creates their User record. This must be resolved before the full migration run — unassigned records create orphaned Events.

Recall and reminder automation must be rebuilt in Salesforce Flow

My Dental Clinic's recall reminders and appointment confirmation workflows are built-in automations tied to patient recall dates. These do not migrate to Salesforce — there is no equivalent native automation in Sales Cloud for dental recall cycles. We export your recall date field and reminder rule configuration as a reference document. Your Salesforce admin rebuilds these as Salesforce Flow triggers on the Contact object using the Next_Recall_Date__c custom field we migrate.