Migrate from Pulse Digital Clinic to Microsoft Dynamics 365 Sales

Pulse patient record maps to a Dynamics 365 Contact. Patient name splits into FirstName and LastName. If the patient has an associated organization, an Account record is created first and Contact.AccountId is set to link them. Demographics (date of birth, gender, address) map to standard Contact fields.

Pulse stores a clinic or organization as a patient record with a 'type' flag. When type indicates a clinic, FlitStack creates an Account record instead and populates clinic name, address, and phone from the Pulse fields. This separation ensures Dynamics 365's Account-Contact relationship model is respected.

Pulse multi-physician module stores physician name, specialty, and registration number. FlitStack matches physician email against Dynamics 365 users to set OwnerId. When no user match exists, a customPractitioner__c table is created in Dataverse to store physician attributes independent of the native User object.

Pulse appointment data (date, start time, end time, physician, status) maps to a Dynamics 365 Appointment record. The Regarding field links to the Contact (patient). Original scheduled-start and scheduled-end times are preserved as custom datetime fields since Activity creation date is set at migration time.

Pulse e-prescribing data (medication name, dosage, prescribing physician, date) has no Dynamics 365 Sales native equivalent. FlitStack creates a custom Dataverse table Prescription__c with a lookup to Contact (patient) and a lookup to Practitioner__c (physician). Prescription history is preserved as a related list on the Contact form.

Pulse billing module stores invoice number, amount, payment date, and status. Dynamics 365 Sales does not handle invoicing; a custom Payment__c table is created in Dataverse with fields for invoice reference, amount, payment date, and status picklist. For full accounting capability, a Business Central integration is recommended post-migration.

Pulse insurance fields (carrier name, policy number, group ID) are split: carrier name becomes a record in a customInsuranceCarrier__c table, and policy number/group ID are custom fields on the Contact record linking to the carrier lookup. This enables carrier-level reporting in Dynamics 365 without duplicating carrier names across contacts.

Pulse clinical notes and EHR summaries are migrated as Dynamics 365 Annotations (notes) attached to the Contact record. FlitStack preserves the original note creation timestamp as a custom datetime field and the authoring physician as the Note.OwnerId for audit traceability.

Pulse campaign management (SMS/WhatsApp outreach) has no native Dynamics 365 Sales counterpart beyond the Campaign entity. FlitStack creates Campaign records to preserve campaign names and target patient counts. The actual message content and sequence logic do not migrate and must be rebuilt in Dynamics 365 Marketing or Power Automate.

Dynamics 365's CreatedOn and ModifiedOn fields are set at migration time by the Dataverse API, overwriting any source timestamps. To preserve the original patient creation and modification dates from Pulse, FlitStack writes them into custom datetime fields (new_originalcreatedon__c and new_originalmodifiedon__c) on each Contact and on relevant custom tables. These preserved timestamps enable historical reporting, support delta‑sync logic, and satisfy audit‑compliance requirements by retaining the original record lifecycle information.

Pulse's internal patient ID is stored as Source_System_ID__c on the Contact record. This field allows FlitStack to perform delta‑run de‑duplication, skipping records already matched, and provides a stable anchor for linking Appointment, Prescription__c, and Payment__c records to the correct patient. It also enables one‑click rollback traceability if a migration run must be replayed, and supports audit logs by associating each migrated entity with its source system origin.

FlitStack reads Pulse patient data via the Pulse REST API (paginated JSON) and writes to Dynamics 365 using the Dataverse Web API. For record sets larger than 10,000, FlitStack uses the Dataverse Bulk API with batch sizes tuned to avoid throttling. Rate limits are monitored per the Power Platform API allocation model.