Migrate from Denticon to Microsoft Dynamics 365 Sales

Denticon Patient maps directly to Dynamics 365 Contact. Name, date of birth, address, phone, email, and emergency contact fields transfer directly as standard Contact attributes. The patient's primary office assignment is stored as a custom Office_ID__c field for reporting segmentation by location, and the original Denticon patient ID is preserved in Source_System_ID__c for deduplication and reconciliation across migration runs.

Denticon patients carry insurance group and employer details that translate to Account records for insurance payers. The primary insurance company name, group number, and plan type map to custom fields on an Account record representing the insurance carrier. Subscriber relationship to the patient is modelled via the Account's Contact sub-grid.

Denticon Insurance Group (plan name, group number, subscriber ID, coverage percentages) maps to a custom Insurance_Coverage__c table linked to both the Account (insurance payer) and the Contact (subscriber). Primary and secondary insurance positions are preserved as separate relationship records, and the effective date and termination date of each insurance plan are stored on the coverage record for eligibility tracking in Dynamics 365.

Denticon's dedicated referral module (source provider, referring office, referral cost, attachment URL, completion status) has no native Dynamics 365 equivalent. We create a Referral_Custom__c custom table with fields for Referring_Provider__c, Referral_Cost__c, Referral_Status__c, and External_Form_URL__c linked to the patient Contact record.

Denticon Providers who are licensed to use Dynamics 365 become System User records, with NPI, license number, and specialty stored in custom fields on the User record. Providers who are not Dynamics users become Contact records with provider-role custom fields. The split is determined by email resolution against the target Dynamics 365 tenant user list.

Denticon OIDs (office identifiers) map to Teams in Dynamics 365 for data access segmentation. The original OID value is preserved in a custom Office_ID__c field on every record. If the DSO uses Business Units for strict data isolation, we create one Business Unit per OID and map the Denticon PGID to the root Business Unit.

Denticon appointments (scheduled date, provider, production type, duration, status) have no direct Dynamics 365 equivalent. We create a custom Appointment__c table linked to the Contact (patient) and User (provider), preserving the original appointment date, production type, and status. Appointment conflicts are flagged during migration if the provider's Dynamics User record does not exist.

Denticon CDT procedure codes, tooth numbers, surface charting, and treatment plan status do not exist in Dynamics 365's standard schema. We create a Treatment_Plan__c custom table linked to Contact, storing CDT_Code__c, Tooth_Number__c, Surface__c, Plan_Status__c, and Proposed_Date__c fields for clinical reference continuity.

Denticon clinical charting notes (AI Assist findings, periodontal recordings, existing conditions, radiograph notes, and oral health observations) are stored as a custom Clinical_Note__c table linked to the Contact, with a free-text Note_Body__c field for raw note content and a Note_Type__c pick-list for categorisation by clinical type. Original clinical note timestamps are preserved on each record for chronological accuracy in the Dynamics 365 timeline.

Denticon's RCM module (claims, payments, adjustments, accounts receivable, clearinghouse status) is scoped out of the CRM migration. Revenue cycle data requires a separate integration with Dynamics 365 Finance or Business Central and is not handled by FlitStack's CRM migration service.

Denticon's Practice Group ID (PGID) — the top-level organisational container above individual offices — maps to the root Business Unit in Dynamics 365. All child OIDs (offices) become child Business Units or Teams under this root, preserving the Denticon PGID hierarchy in the Dynamics 365 Business Unit tree.

Denticon subscription and contract records tied to specific payers or service agreements are stored as a custom Subscription__c table linked to the Account, preserving start date, end date, contract type, and monthly rate fields for continuity in the CRM layer.