Migrate from Nookal to Microsoft Dynamics 365 Sales

Nookal patients map to D365 Sales Contacts. The patient's primary clinic or referring practitioner creates an Account record first; the Contact links via the Parent Customer ID (AccountId). Patient date of birth, medicare_number, and NHS_number (if applicable) migrate as custom fields since D365 Sales has no native health-ID storage. FlitStack AI creates the Account record from the patient's associated clinic or referring location before creating the Contact so the AccountId foreign key resolves correctly.

Practitioners are the primary actors in Nookal — they own appointments, clinical notes, and billing. They map directly to D365 Sales Users. practitioner.name becomes Full Name on the User record; practitioner.email becomes User Name; practitioner.role or specialty becomes a custom field (Specialty__c). FlitStack AI resolves each practitioner by email against existing D365 Sales Users before migration; unmatched practitioners are flagged so they can be provisioned in D365 before the cutover window opens. Practitioner Location associations migrate as a custom field (Location_ID__c) on the User record.

Each Nookal appointment maps to a D365 Sales Task (for general sessions) or Event (for calendar-scheduled appointments). appointment.start_time and end_time map to ScheduledStart / ScheduledEnd on the Event; appointment.notes map to Description; practitioner_id resolves to OwnerId by email match. The Nookal appointment ID is stored as Appointment_ID__c for traceability and delta-run de-duplication. The patient contact links via the Regarding (regardingobjectid) lookup on the Activity record.

D365 Sales has no native invoice entity. FlitStack AI creates a custom Invoice table in Dataverse with fields: Invoice_Number__c (text), Invoice_Date__c (datetime), Total_Amount__c (currency), Status__c (optionset: Paid / Unpaid / Overdue), and Patient__c (lookup to Contact). Invoice line items are stored in a second custom table (Invoice_Line_Item__c) linked to the Invoice record. Medicare item codes on invoices are preserved in the line item table as Item_Code__c for reference — they have no D365 Sales equivalent and must be manually reconciled post-migration.

Nookal clinical notes contain subjective, objective, assessment, and plan sections tied to a specific appointment. D365 Sales has no native clinical documentation entity. FlitStack AI creates a Clinical_Note__c custom table with fields: SOAP_Subjective__c, SOAP_Objective__c, SOAP_Assessment__c, SOAP_Plan__c (all text), Patient__c (lookup to Contact), Appointment_ID__c (text for reference), Created_Date__c (datetime to preserve original timestamp), and Practitioner__c (lookup to User). Each note is created after the related Contact and Activity records exist to satisfy the lookup foreign keys.

Nookal Medicare and DVA claiming records — including item codes, bulk-billing flags, and claiming status — have no native equivalent in D365 Sales. FlitStack AI preserves Medicare item codes and claiming data as a custom field block (Medicare_Claim__c JSON blob or individual fields) on the Invoice record for reference, but Medicare claiming must be rebuilt separately using D365 Sales custom tables or an integration with Australian claiming software. This is surfaced explicitly in the pre-migration plan as a manual-rebuild item.

Nookal supports multiple clinic locations with practitioner assignment per location. D365 Sales has no native multi-location structure. FlitStack AI creates a Location_ID__c custom field on both the User (for practitioner location) and Contact (for patient location) records. If the clinic has fewer than 5 locations, a Territory__c custom pick-list is used instead of a text field for cleaner reporting segmentation.

Nookal payments against invoices map to the D365 Sales Invoice custom table (Payment_Status__c updated to Paid) or, if payments need to be tracked against cases, as Opportunity Product records tied to the relevant Contact's Case opportunity. Payment date, amount, and payment method are preserved as custom fields. Unallocated receipts are flagged in the migration report for manual resolution.

Nookal tracks where patients were referred from (GP referral, self-referral, etc.). D365 Sales has no native referral-source field on Contact. FlitStack AI creates a Referral_Source__c custom pick-list field on the Contact object and maps each Nookal referral value to the corresponding pick-list value. Unknown or unmapped values are preserved as text in a secondary field (Referral_Source_Other__c) for admin review.

Nookal appointment types (Initial Consultation, Follow-Up, etc.) carry Medicare item codes and billing implications. D365 Sales Activities have no native service-type field. FlitStack AI creates a Service_Type__c custom pick-list on the Task/Event and maps Nookal appointment types. Where a service type implies a Medicare item code, the item code is stored in a companion field (Item_Code__c) on the Activity for downstream reconciliation.