Migrate from Phreesia to Odoo CRM

Phreesia intake answers and clinical screening results have no native Odoo CRM equivalent and require custom field creation before data lands

Phreesia stores intake form responses and clinical screening results as structured data fields tied to a patient record, but Odoo CRM has no out-of-the-box model for this healthcare-specific content. The migration requires pre-creating custom fields on res.partner and crm.lead for every distinct intake question and screening type before records can be written. If an organization has 20 custom intake fields, all 20 must be defined as Odoo custom fields (with correct field types: Char, Selection, Boolean, Date, Float) and mapped row-by-row. FlitStack AI generates a field-creation specification during the planning phase so the Odoo schema is ready before any data moves. This is the single largest driver of migration timeline and cost for Phreesia-to-Odoo projects.

Phreesia appointment scheduling data maps to static fields on crm.lead, not native Odoo calendar events

Odoo CRM does not include a native appointment scheduling module in its base installation — calendar management is handled by Odoo's separate Calendar application (calendar.event), which operates independently of the CRM and requires its own configuration. Phreesia appointment dates, times, and provider names cannot automatically create calendar.event records during migration because the appointment-to-activity mapping requires Odoo Calendar app to be installed and because Phreesia's visit-outcome data (no-show, completed, rescheduled) does not map directly to any Odoo event status. FlitStack AI migrates appointment dates and provider names as custom Char and Date fields on crm.lead and documents the Odoo Calendar configuration steps as a post-migration task. Teams expecting automated scheduling continuity will need to rebuild appointment workflows in Odoo Calendar or a third-party scheduling integration.

Phreesia's scoped read access model means only the exporting organization's data is accessible — no multi-location aggregation at migration time

Phreesia's API access is scoped to the specific clinic or health system account authenticated during the migration. Organizations operating multiple Phreesia locations (each with a separate Phreesia deployment) must run separate export cycles per location and merge the resulting datasets in Odoo as distinct res.partner records with a custom location_id field. There is no aggregation endpoint that pulls all locations into a single export. This becomes significant for health systems with 5+ locations where each location has independent Phreesia configurations and intake form variants. FlitStack AI flags multi-location scope during discovery and sequences location-by-location exports with a cross-location deduplication pass before loading into Odoo.

Phreesia workflows, consent automation, and intake routing rules do not exist in the API export and cannot migrate to Odoo automatically

Phreesia's intake workflow engine — the rules that govern which forms appear based on appointment type, which reminders fire, and how consent captures route to the PM/EHR — runs as internal Phreesia configuration that is not exposed via API or export. When migrating to Odoo CRM, these workflow constructs have no data representation to extract. The equivalent in Odoo is base.automation (automated actions triggered on record creation or field change) and mail.activity, which must be configured manually based on exported Phreesia workflow definitions. FlitStack AI provides a workflow audit export from Phreesia's documentation and a corresponding Odoo automation rebuild guide as part of the migration package, but the Odoo-side automation must be built by an Odoo administrator or consultant post-migration.

Insurance eligibility verification flags from Phreesia do not trigger re-checks in Odoo — coverage status becomes a static field

Phreesia runs real-time eligibility verification against payer systems and stores the result (active, inactive, pending, unknown) as a status flag on the patient record. When this data migrates to Odoo as a custom Selection field, it becomes a snapshot in time — it does not automatically re-verify eligibility. Over time, the Odoo insurance_status__c field will become stale unless manually updated or connected to a third-party eligibility verification service (e.g., Availity, Waystar) via Odoo's web API or a middleware integration. FlitStack AI surfaces this as a migration gotcha and provides a reconciliation workflow template that Odoo's admin can schedule as a periodic manual review or API-based re-check against the existing payer portal.