Migrate from tab32 to Microsoft Dynamics 365 Sales

Patient record maps directly to Contact. The tab32 Patient includes demographics, contact info, insurance, and clinical history. We extract demographics and contact info into Contact fields; clinical history becomes a custom dental examination table or JSON blob in a custom column for reference.

Patients who have not yet been seen (inactive or prospective patient records in tab32) can route to Dynamics 365 Lead. Active patients with treatment history route to Contact. We use the patient status field in tab32 to determine the split; inactive status means Lead, active status means Contact.

tab32 practice/location records map to Account in Dynamics 365. Practice name becomes Account Name, address maps to address1 fields, phone to telephone1. Multi-location DSOs produce multiple Account records. Dynamics Account hierarchy (Parent Account) can represent DSO structure if tab32 has a parent-company field.

tab32 appointments become CRM Activities. We map appointment date/time to Task ScheduledStart/ScheduledEnd or Appointment Start/End Time. Provider resolves by email match to Dynamics 365 SystemUser. Appointment type becomes Task Subject. Clinical context (procedure codes, operatory) requires custom fields on the Task record.

Treatment plans map to Opportunities in Dynamics 365. The treatment description becomes Opportunity Name or Description. Total treatment cost maps to Estimated Revenue. Status maps to Opportunity Stage (Proposed, In Progress, Won, Lost). Each treatment plan line item (CDT codes with fees) becomes an Opportunity Product.

CDT (Current Dental Terminology) codes are industry-standard dental procedure identifiers. We map the CDT code to Product Number (or a custom cdt_code__c field), the description to Product Name, and the fee schedule amount to Price (per Price List). Products are linked to Opportunity records via Opportunity Product line items.

Tooth charting records — which track surface conditions per tooth using FDI or Universal numbering — have no Dynamics 365 Sales equivalent. We create a custom Dental_Chart__c table in Dataverse keyed to the Contact (patient). Each tooth surface condition (M, O, D, B, F, etc.) maps to custom columns. Sales Professional users are capped at 15 tables; this may require Sales Enterprise.

Periodontal examination records (pocket depths, gingival recession, mobility, furcation) have no CRM equivalent. We create a custom Perio_Exam__c table with per-tooth measurements linked to the Contact record. Date of exam and provider are preserved as standard fields; pocket depth values per tooth use custom decimal columns.

tab32 provider records represent clinical staff (dentists, hygienists, assistants). We map them to Dynamics 365 SystemUser (if they are CRM users) by email match, or to Contact if they are not system users. Provider specialty and license numbers migrate as custom fields on the SystemUser or Contact record.

Insurance carriers from tab32 patient records can be consolidated into Account records with a custom Account Type = 'Insurance Carrier'. Alternatively, we extract unique carriers into a custom Insurance_Carrier__c table. Carrier addresses and contact info map to standard Account address and phone fields.

Dental claims have a complex lifecycle (submitted, pending, paid, denied) that Dynamics 365 Invoice does not model. We map paid amounts to Invoice for financial tracking. Claim status, carrier response, and adjustment codes go to a custom Claim__c table linked to the Contact (patient) and the treatment plan Opportunity.

tab32 fee schedules are per-practice or per-specialty fee tables. We map these to Dynamics 365 Price Lists attached to Products (CDT codes). Multi-location DSOs with different fee schedules per practice require multiple Price Lists, each linked to the corresponding Account (practice location) or to a custom pricing structure.

tab32 stores intraoral images, X-rays, and documents attached to patient records. We re-upload these to Dynamics 365 as Notes with file attachments. Original file names and upload dates are preserved. Large imaging files may exceed Dynamics 365 default file size limits (25MB per file) — we flag oversized files before migration.

tab32 two-way texting and email logs migrate as CRM Activities. Emails become Email activities (Activity Type = 'Email') with the original timestamp and content preserved as the Description field. Text messages migrate as custom Activity records or as Notes if the Dynamics version supports SMS logging natively.

tab32 offers Open Data Warehousing as a BI layer on top of their platform — a significant differentiator for DSOs using analytics. Dynamics 365 has Dataverse as its data layer and Power BI for reporting. We do not migrate the warehouse itself; BI/reporting must be rebuilt in Power BI using Dataverse as the source.