Migrate from axiUm Dental to Salesforce Sales Cloud

axiUm Patient Card holds patient demographics, guarantor info, and insurance fields. We split these: name/email/phone/address → Salesforce Contact; guarantor organization and insurance plan → Account with custom fields (Guarantor_Name__c, Insurance_Plan__c). The Patient Card's financial balance migrates as a custom currency field on Account.

Emergency contact fields on the Patient Card have no direct Salesforce equivalent. We map them as a custom object (Emergency_Contact__c) with a lookup to the primary Contact record, preserving name, relationship, and phone. Each Emergency_Contact__c record includes a Relationship_Type__c pick-list and an Effective_Date__c field to track when the contact became active, supporting audit trails for insurance and consent workflows.

Each axiUm appointment maps to a Salesforce Event (for scheduled chair-time with start/end datetime, appointment type, provider, and operatory). Recall appointments and waitlist entries map to Salesforce Tasks with custom Type__c pick-list values 'Recall' and 'Waitlist' so your team can filter them in list views.

axiUm clinical procedures (procedure code, tooth number, surface, provider, date, fee) map to a custom Procedure__c object with a lookup to Contact and Opportunity. If the procedure is billable, we also create an Opportunity Line Item or a custom Billable_Procedure__c field on the Opportunity to support revenue reporting in Salesforce.

The axiUm billing ledger (charges, payments, adjustments, insurance payments, write-offs) has no Salesforce standard equivalent. We create a Billing_Ledger__c custom object linked to Account, preserving transaction date, type, amount, and carrier — giving your billing team a full ledger view inside Salesforce.

The axiUm odontogram (32 teeth × surfaces with conditions: Decayed, Filled, Missing, Crown, etc.) is a complex grid stored as structured data. We create an Odontogram__c custom object with a tooth-number pick-list (Tooth_Number__c), surface pick-list (Surface__c), condition text (Condition__c), and date — one row per tooth-surface entry, linked to Contact.

axiUm perio pocket measurements (6 sites per tooth × 32 teeth = 192 values per visit) migrate as a custom Perio_Record__c object with a visit date, tooth number, site (Mesial/Distal/Facial/Lingual), pocket depth in mm, BOP flag, and mobility — linked to Contact and the corresponding Procedure__c record.

Free-text clinical notes from axiUm's EHR module map to Salesforce Notes (the modern Notes object, not the legacy Note). Each note preserves the original create date, author/provider name, and parent-contact link. If notes contain sensitive PHI that needs structured fields, we offer a custom Clinical_Note__c object with a rich-text Body__c field.

axiUm custom forms (Medical History, Health Updates, Consent forms) contain practice-specific fields. We export the form schema and create a corresponding custom object in Salesforce (e.g., Medical_History__c) with one field per form element, linked to Contact. Form responses migrate as records in Salesforce; the form template itself is exported as a PDF reference document.

axiUm scanned consents, imaging exports, and document attachments re-upload to Salesforce Files. We preserve the original filename, content type, and attach them to the corresponding Contact or Procedure__c record via ContentDocumentLink. File size limits (Salesforce default 25MB per file) are flagged for oversized imaging files.

axiUm provider records (dentist, hygienist, assistant, office manager) resolve by email match against Salesforce Users. Unmatched providers are flagged as inactive User records with a Source_System_Provider__c flag so the Salesforce admin can activate and assign them after the migration. Provider specialty and license information can be stored in custom fields on the User record, enabling accurate task routing and reporting based on provider type.

axiUm tracks CODA-accreditation requirements (student procedure completions, clinical competencies, evaluation scores) that have no Salesforce standard object. We export these as records in a custom Accreditation_Tracking__c object linked to Contact (student) and the Procedure__c record — rebuild of the evaluation logic in Salesforce Flow is required separately.