Migrate from The Dental System to Twenty CRM

The Dental System patient record is the primary unit of migration. Name, email, phone, address, and all dental-specific properties transfer to a Twenty People record. The patient's primary provider resolves to a Twenty Workspace Member by email match before the People record is created.

The Dental System stores the next recall date as a patient property. Twenty has no native recall field — FlitStack creates a custom date field (Recall_Due_Date__c) on the People object. The original recall-interval logic (e.g., 6-month hygiene) is preserved as a text note on the People record for the dental office admin to rebuild as a workflow trigger.

The Dental System tracks the last completed hygiene visit per patient. FlitStack creates a custom date field (Last_Hygiene_Visit__c) on the People record to preserve this clinical milestone. After migration the field serves as the anchor date for overdue‑hygiene reports, patient‑lapse segmentation, and recall‑workflow triggers in Twenty's builder. The original visit timestamp is retained as a static value; any subsequent visits must be logged directly in Twenty.

The Dental System stores the dollar value of recommended but uncompleted treatment per patient. This migrates as a custom currency field (Outstanding_Treatment_Value__c) on the People record. It does not transfer to a Twenty Opportunity unless the treatment converts to an active deal — the dental office decides that post-migration.

The Dental System stores the insurance carrier as a patient sub-field. FlitStack creates a custom text field (Insurance_Carrier__c) on the People record. If the carrier name matches an existing Twenty Company, FlitStack also creates a Company relation on the People record.

Policy number migrates as a custom text field (Insurance_Policy_Number__c) on the People record. It is stored from Insurance_Carrier__c; each can be used in filter conditions and workflow rules. FlitStack maps the policy string to the field and logs it in the migration manifest. It can feed segmentation rules, task triggers, and dashboards. If the policy number should match an existing Company, the admin can link it manually after import.

Insurance group number migrates as a custom text field (Insurance_Group_Number__c) on the People record. This field is distinct from the policy number and carrier name. FlitStack maps the group string to the field and logs it in the manifest. As text, it can be used in filter conditions, segmentation, and workflow rules directly. If the group number corresponds to an existing Company, the admin may link it manually after import.

The Dental System's internal patient identifier migrates as a custom text field (Source_System_ID__c) on the People record. FlitStack marks this field as unique, preventing collisions on subsequent imports. The unique constraint supports delta‑run de‑duplication, audit trails, and cross‑system reconciliation with the original PMS. After migration the field can be used in filters, linked relations, and API queries to reference the source patient record directly.

The Dental System stores the primary dentist's name as a string on the patient record. FlitStack resolves this name to an existing Twenty Workspace Member by email domain or name match. If no match is found, the provider name is stored as a custom text field (Primary_Dentist__c) on the People record for manual assignment post-migration.

The Dental System stores clinical notes per patient visit. Each note migrates as a Twenty Note linked to the corresponding People record. Original timestamps and provider attribution are preserved as Note metadata. Long notes exceeding Twenty's field length are split into multiple Note records.

Patient appointments (cleaning, exam, procedure) migrate as Twenty Tasks linked to the People record. Task subject uses the appointment type from The Dental System, start date uses the appointment date, and the assigning Workspace Member is resolved from the provider name. Completed vs. scheduled status maps to Task completion.

Referral source recorded in The Dental System (e.g., patient referral, external referral, marketing campaign) migrates as a custom text field on the People record. If The Dental System uses a pick-list, FlitStack creates a custom select field with the same options.

Street address, city, state, and postal code on the patient record map to Twenty's native address fields on the People object. FlitStack normalizes the source address strings, splitting them into the appropriate sub‑fields (street, city, state, postal code) to match Twenty's expected structure. After migration the normalized address can be used for region‑based segmentation and task triggers based on location.

If The Dental System stores the practice or location as a separate entity, it maps to a Twenty Company record. The Company record holds the practice name, address, and phone. Patient records link to the Company via the People.companyId relation.