Migrate from DGL Practice Manager to Salesforce Sales Cloud

DGL patient records map to Salesforce Account objects. Each patient becomes one Account with patient type set via a custom Account Type pick-list (e.g., 'Private Patient', 'NHS Patient'). The Account.Name field uses the patient's full name. Address, phone, and email map directly. Original DGL patient ID stored as Source_System_ID__c for traceability.

DGL practitioners (consultants, GPs, secretaries) map to Salesforce Contacts under the primary clinic Account. Each practitioner gets one Contact record with specialty, GMC/GDC number (stored in a custom field), and role. Unassigned practitioners (e.g., referring doctors external to the practice) get their own Contact records with no Account link.

DGL's relationship between a patient record and the responsible practitioner maps to Salesforce's AccountContactRelation junction object. The IsPrimary__c flag marks the lead consultant for each patient. This junction supports N:1 patient-to-practitioner relationships — critical for clinics where patients see multiple consultants.

DGL appointments have no Salesforce standard equivalent. We create a custom Appointment__c object with fields for AppointmentDate__c, StartTime__c, EndTime__c, AppointmentType__c, Status__c, and a lookup to the patient Account and practitioner Contact. If your practice uses a separate scheduling tool post-migration (e.g., Calendly, Acuity), the Appointment__c records serve as historical reference.

DGL clinical notes and letter content migrate as Salesforce Notes attached to the patient Account. The Note.Title uses a standardized format (e.g., 'Letter – [Date] – [Author]'), and the Body field contains the full note text. Original author, creation date, and last-modified date are preserved. Note: Salesforce Notes have a 32KB body limit per record — very long letters are split into multiple Notes with sequence numbering.

Outgoing correspondence from DGL maps to Salesforce Tasks with Type='Correspondence', Subject containing the recipient and date, and Status='Completed'. The Task is linked to the patient Account. Inbound correspondence received via email can be logged as Task records with Subject and Description fields populated from the source.

DGL invoice records (including EDI insurer submissions and automatic shortfall calculations) map to a custom Invoice__c object with fields for InvoiceNumber__c, InvoiceDate__c, TotalAmount__c, AmountPaid__c, Balance__c, InsurerName__c, and Status__c pick-list (Draft, Sent, Paid, Partially Paid, Written Off). The invoice is linked to the patient Account and optionally to an Opportunity if the invoice relates to a billable event.

DGL referral tracking (which GP, hospital, or other source referred the patient) maps to Referral_Source__c (text or pick-list depending on volume) and Referring_Practitioner__c (lookup to the referring practitioner's Contact record) on the patient Account. This preserves referral network intelligence for marketing and reporting in Salesforce.

DGL insurer billing fields (insurer name, policy number, membership ID, pre-authorization code) map to custom fields on the patient Account: Insurer_Name__c, Policy_Number__c, Membership_ID__c, Preauth_Code__c. These support Salesforce reports on insurer mix and claim tracking without requiring a full insurance module.

DGL's patient flags for allergies, medical conditions, and special notes migrate to custom fields on the patient Account: Patient_Allergies__c (long text area), Medical_Conditions__c (long text area), and Special_Notes__c (text). These are rendered on the Account page via a custom Lightning component if your Salesforce admin activates it.

DGL file attachments (scanned documents, PDF letters, imaging referrals) re-upload to Salesforce Files and are linked to the parent patient Account via ContentDocumentLink. File size limits of 25MB per file apply (Salesforce default); files larger than this are flagged and handled as external document links stored in a custom URL field.

DGL's practitioner diary and resource scheduling configuration (diary templates, room bookings, session types) has no Salesforce standard equivalent and cannot be migrated as structured data. FlitStack exports diary configuration as a structured PDF reference document for manual rebuild in your chosen scheduling tool (e.g., Salesforce Scheduler, Calendly, Acuity).

DGL system preferences (letterhead templates, auto-population rules, clinical template defaults) are DGL-specific application configuration that do not map to Salesforce. These must be rebuilt manually in Salesforce's Letterhead, Email Templates, and Flow tools, or reconfigured in your chosen document generation tool.

DGL's workflow rules (e.g., automatic letter generation on appointment confirmation, insurer claim triggering on invoice creation) do not migrate. FlitStack exports DGL workflow definitions as a structured Word document for your Salesforce admin to rebuild in Flow. Any automations involving appointments must be rebuilt in your chosen scheduling tool's automation layer.