Migrate from Core Practice to Twenty CRM

Core Practice Patient records migrate as Twenty People. The email address (if present) becomes the unique identifier for People import. Patients without emails are imported with a generated placeholder and flagged for review. Name, phone, address, and DOB map directly; Core Practice patient_id stored as source_patient_id__c for traceability.

Core Practice stores address components as separate fields. These combine into a structured address block in Twenty People. We validate state abbreviations and postal code formats before import to prevent malformed address records in Twenty. For international addresses, we also normalize country names and apply the appropriate Two‑letter ISO code, ensuring consistency across all address records in Twenty.

Core Practice Practice entity (clinic name, address, phone) migrates as a Twenty Company record. For multi-location dental groups, each Core Practice location becomes a separate Company record. If the group name is needed as a parent, we use Twenty's parent_company_id field to build the hierarchy.

Core Practice Appointments with status Scheduled, Completed, Cancelled, or No-Show become Twenty Tasks. The appointment datetime maps to dueDate and dueStatus on the Task. The associated patient and doctor link via their Twenty record IDs. We also capture appointment_type and procedure codes as custom fields on the Task for audit continuity.

Core Practice Doctor records (name, specialization, email) migrate as People records in Twenty with a custom Doctor_Specialization__c field. Doctor email resolves against Twenty Workspace Members — if a match is found, the doctor gets a Twenty user account and ownership of their associated appointment Tasks.

Core Practice Treatment Plans (procedures, estimated cost, status: Proposed, In-Progress, Completed) have no direct equivalent in Twenty's standard objects. We create a TreatmentPlan custom object in Twenty with fields for procedure_name, treatment_status, estimated_cost, and associated Patient via a relation field. This is the most common schema extension for dental-to-Twenty migrations.

Core Practice Invoices carry line items, totals, and payment status (Paid, Outstanding, Overdue) with no native equivalent in Twenty. We migrate Invoice records as a custom Invoice object in Twenty for reference — actual payment processing must remain in Core Practice or move to a dedicated billing tool post-migration.

Core Practice Insurance Claim records (claim_id, status, amount, patient) migrate as a custom InsuranceClaim object in Twenty. This captures the financial context of each patient relationship without requiring a billing module in Twenty. The custom InsuranceClaim object stores claim_date, provider_name, service_code, and payer as custom fields, and maps Core Practice claim status to a pick‑list (Submitted, Pending, Approved, Denied, Paid).

Core Practice clinical notes and free-text observations migrate as Twenty Notes attached to the corresponding Patient record. Original note timestamps and doctor attribution are preserved as custom fields on the Note object in Twenty. We preserve the full note body as plain text, set the note's visibility to the assigned doctor and relevant staff, and include a reference to the original Core Practice note ID for audit traceability.

File attachments stored in Core Practice (X-ray images, signed forms, treatment PDFs) are downloaded and re-uploaded to Twenty's file storage. File associations to Patient records are preserved. Maximum file size limits from Twenty's storage backend apply — large imaging files may require compression or separate cloud storage with a link stored in Twenty.

Core Practice patients belong to a Practice entity. After the Practice migrates to a Twenty Company, we link each Patient to that Company via the companyId field on the People record. Multi-location patients (seen across practices) require the patient's primary practice to be designated for the companyId lookup.

Core Practice workflows (appointment reminders, patient recall sequences, insurance expiration alerts) do not migrate. These automations must be rebuilt in Twenty's Workflow builder. We export workflow definitions as JSON reference files so your admin can recreate the logic step-by-step in Twenty.

Core Practice invoice and payment tracking is a billing construct with no Twenty CRM equivalent. We preserve invoice number, status, and outstanding balance as custom fields on a reference Invoice custom object in Twenty, but actual payment processing, line-item billing, and insurance claim adjudication must continue in a dedicated billing tool.