Migrate from Pulse Digital Clinic to Pipedrive

Pulse patient records map to Pipedrive Person objects. First name, last name, email, phone, and address fields migrate directly. Medical fields (allergies, blood_type, medical_history) create as Pipedrive custom fields on the Person record after hash-key registration via the Pipedrive API.

Pulse clinic name and address data maps to a Pipedrive Organization record representing the clinic itself. If Pulse stores referring clinics or insurance providers as separate entities, each becomes its own Organization record with type distinguished via a custom field.

Pulse appointment records with date, time, duration, status, doctor name, and appointment type map to Pipedrive Activity records. The Person record is linked via Pipedrive's activity_participants API field. Appointment status (completed, no-show, cancelled) maps to Pipedrive activity status values (not done, completed).

Insurance carrier data from Pulse—including provider name, policy number, and group ID—maps to Pipedrive Organization records tagged with a custom insurance_provider_type pick‑list field. If a patient has multiple carriers, each carrier is created as a separate Organization. FlitStack captures the mapping of Pulse carrier IDs to Pipedrive org IDs and sets Person.org_id to the primary carrier; additional carriers are linked via a custom multi‑reference field or notes.

Billing amounts, payment status, and outstanding balance from Pulse's billing module migrate as custom fields on the Person record (or optionally as Deal records if the clinic prefers a Pipedrive billing pipeline view). Payment status values (paid, pending, overdue) require value mapping to Pipedrive pick-list custom field options.

Pulse prescription data—medication name, dosage, frequency, prescriber, date, and refills—maps to Pipedrive custom long‑text fields on the Person record. For patients with multiple prescriptions, FlitStack concatenates entries with line breaks to keep each medication readable. Prescriber is resolved to a Pipedrive User where possible, and any extra metadata is stored in supplemental custom fields. Content over 10 000 characters is split, attached as a file, and flagged.

Pulse records each patient’s original create_date and last_modified timestamps, which reflect when the record was first added and last edited. Pipedrive sets its own CreatedDate at import time, so the original Pulse timestamps are saved as custom fields named Original_Create_Date__c and Original_Last_Modified__c on the Person record. These fields enable audit reporting, help identify stale records, and support delta‑sync logic that captures any Pulse changes made after the migration window closes.

Pulse’s internal record ID is saved as Source_System_ID__c on each Pipedrive Person record. This provides a stable link to the source system, enabling FlitStack to de‑duplicate records on delta runs, match related objects (appointments, bills) back to the original Pulse entry, and support error‑resolution workflows that reference the source identifier. The ID remains unchanged across updates.

Pulse practitioner names on appointments map to Pipedrive User records by email match. If Pulse stores practitioner records with email addresses, FlitStack resolves the owner by email lookup. Unmatched practitioners are flagged before migration and assigned to a fallback Pipedrive user.

Pulse clinics tag patient, appointment, and organization records with location identifiers to separate branches. Pipedrive lacks a native multi‑location model; all records live in one account. FlitStack creates a custom pick‑list field named location_id and populates it on Person, Organization, and Activity records using the value extracted from Pulse. If the clinic later enables Pipedrive’s Enterprise visibility groups, the same location_id can be used to enforce data isolation per branch.