Migrate from Phreesia to Freshsales

Patient first name, last name, email, phone, address, and date of birth map directly to Freshsales Contact standard fields. Email serves as the unique identifier for de-duplication across the migration. Phone number maps to Freshsales Contact.phone, and mobile phone maps to Contact.mobile. The composite address object on Contact receives the street, city, state, zip, and country fields from Phreesia. Date of birth maps to Contact.date_of_birth. This direct field mapping preserves all core demographic data without transformation.

Phreesia patient records are undifferentiated — every record is a patient regardless of appointment status. We apply a lifecycle routing rule: patients with at least one completed appointment in Phreesia migrate to Freshsales Contact; those with only scheduled but not-yet-completed appointments route to Freshsales Lead. This split is determined by querying Phreesia appointment records for each patient during migration and applying the routing rule consistently.

Freshsales has no native insurance object. Payer name, policy number, group ID, and coverage status migrate to custom text fields on Contact. Insurance type (commercial, Medicare, Medicaid) maps to a custom dropdown. These fields require Freshsales Pro or Enterprise for advanced dropdown types.

Each completed appointment becomes a Freshsales Deal. The Deal name uses the appointment date plus provider name. If the appointment generated a billing amount, that value maps to Deal.amount. Otherwise, amount is set to zero and a custom Appointment_Type__c field records the visit type. Pipeline and stage are set to default values unless the organization defines custom pipelines.

Each completed appointment in Phreesia generates a Freshsales Task record for follow-up tracking purposes. The Task captures appointment date, provider name, and appointment status. Tasks are linked to the corresponding Contact via the foreign key relationship, preserving a complete appointment history within Freshsales even for visits that generated no billing amount and therefore have no associated Deal record.

Consent form completion records including form name, signed date, and consent type are written as Freshsales Notes attached to the Contact record. The consent form name becomes the Note title, the signed date maps to Note.created_at, and the full consent text content is stored in the Note body field. This approach preserves the complete consent audit trail without requiring custom objects or advanced field types on any Freshsales plan tier.

Phreesia's logic-driven intake questionnaires (conditional questions, clinical screening logic, custom response validation) have no Freshsales equivalent. These must be rebuilt manually using Freshsales web forms, Typeform, or a similar tool. We document the Phreesia form structure for the rebuild team.

Phreesia stores card-on-file tokens and payment history for time-of-service collection. Freshsales has no native payment or billing object. Payment tokens do not migrate. We document the payment method on file as a Note for reference; actual payment processing stays in Phreesia or moves to a dedicated payment platform.

Patient-reported screening results (PHQ-9, tobacco use, social determinants) collected during Phreesia intake migrate to custom fields on Contact. Field types depend on the result format: numeric scores use Number fields; yes/no outcomes use Checkbox; categorical results use Dropdown. Growth plan users may need to upgrade to Pro for advanced field types.

Phreesia provider and staff records resolve by email match to Freshsales User accounts. Unmatched providers are flagged before migration — the team either provisions Freshsales users first or assigns records to a fallback owner. Provider specialty maps to a custom User field.

Phreesia's bidirectional EHR and PM integrations including eClinicalWorks, Epic, and athenahealth are destination-specific configurations stored within Phreesia that do not export via API. These integrations must be rebuilt in Freshsales through the Freshworks Marketplace or using middleware such as Zapier or a custom API integration. We document the current Phreesia integration flow in detail for the rebuild team to reference during reconstruction.

The original Phreesia patient record identifier is preserved as a custom text field (Phreesia_Patient_ID__c) on the Freshsales Contact during migration. This custom field enables delta-run de-duplication checks, prevents duplicate record creation on subsequent migration runs, and provides traceability back to the source Phreesia system for reconciliation and audit purposes after migration completion.