Migrate from Phreesia to Salesforce Sales Cloud

Phreesia has no public REST or Bulk API — data export depends on managed export endpoints scoped to the customer's own Phreesia environment

Phreesia does not expose a documented public API for customer-driven data extraction. FlitStack accesses Phreesia's authenticated data-export endpoints under the customer's own Phreesia session credentials. Export speed is constrained by Phreesia's internal export job processing — large patient-record sets (200,000+) require staged export runs rather than a single bulk pull. If Phreesia has restricted API access for the customer's tier or contract, migration planning must account for manual export preparation or Phreesia-assisted export requests before the migration run. We surface any API access constraints during the discovery phase before committing to a timeline.

Phreesia intake form fields are not exposed as named API fields — each organization's form field schema must be extracted and mapped individually

Phreesia intake forms are configured per organization, and form field definitions are not available via a standard API field listing. FlitStack extracts the intake form field schema by parsing Phreesia's export output headers and cross-referencing them against the organization's intake form configuration documentation. If the organization cannot provide intake form documentation, we extract a representative patient record with all form fields populated and infer the schema from the populated field names. This manual schema-introspection step adds planning time — organizations with more than 50 intake form fields across multiple form types should plan for an additional 1–2 days of schema mapping before the migration run.

Salesforce Contact does not have a native patient-type flag — patients and non-patient contacts share the same object

Salesforce's standard Contact object does not have a native 'patient' versus 'business contact' distinction. Healthcare organizations migrating from Phreesia use the Contact object for all patient records, which means Salesforce reports and list views cannot filter 'patients' without a custom flag. We create a Phreesia_Patient__c checkbox field on Contact set to true for every Phreesia patient record. This flag enables report filters, list views, and Flow triggers that need to act only on patient contacts. Organizations that also use Salesforce for non-patient business contacts (vendor contacts, referring physician contacts) should plan for data governance rules around the patient flag to avoid accidental marketing touches to patient contacts.

Phreesia appointment history must be loaded as Salesforce Tasks or Events — but Salesforce Tasks cap at 50 custom fields per object

Salesforce Task objects support a maximum of 100 custom fields total, but the effective limit in most orgs is lower depending on storage and field-type mix. Phreesia appointment records can carry 10–15 metadata fields (type, provider, location, status, duration, chart number, referring provider, visit cost, copay amount, insurance claim status). If your Phreesia appointment schema has more than 12 metadata fields, some lower-priority fields must be consolidated into a single long-text-area field (e.g., Appointment_Metadata__c) storing JSON-serialized remaining fields rather than individual custom fields. We audit the appointment field count during discovery and flag this consolidation requirement before the migration run.

Clinical screening data stored as Phreesia structured records requires a custom object — standard Salesforce objects cannot model PHQ-9 or SDOH results

Phreesia's clinical screening records (PHQ-9 depression screening, social determinants of health surveys, fall-risk assessments) are structured data records with typed result fields. Salesforce's standard Case, Task, and Event objects cannot model these screening results in a way that preserves the screening type, result score, and clinical thresholds. We create a Phreesia_Screening__c custom object with a Contact__c lookup, Screening_Type__c pick-list, Result_Value__c, and Collected_Date__c. However, Salesforce's custom-object creation requires the organization's Salesforce admin to approve the custom object in Setup or grant FlitStack an Integration User license with custom-object create permissions. If your Salesforce org has a locked-down Setup profile policy, custom-object creation must be pre-approved before the migration run begins.