Migrate from tab32 to Freshsales

tab32 patient demographics (name, DOB, contact info) map directly to Freshsales Contacts. Insurance carrier, group/subscriber IDs, recall frequency, and preferred provider preserve as Freshsales custom fields on the Contact. tab32 patient records without a linked procedure may be archived rather than migrated.

tab32 appointments map to Freshsales Activities (tasks or events). Appointment date, time, provider, status, and location transfer as standard activity fields. CDT procedure codes and appointment sub-type (hygiene, perio, specialist) migrate as custom fields. The clinical tooth chart and perio exam results have no Freshsales home — these transfer as a long-text Note or stay in tab32 as a reference link.

tab32 provider records (dentist, hygienist, assistant) map to Freshsales Users by email address match. Provider role (dentist vs. hygienist) migrates as a custom text field since Freshsales User profiles do not have a role taxonomy. Unmatched providers are flagged before migration.

tab32 practice or DSO location names map to Freshsales Account Name. Practice address, phone, and timezone transfer as standard Account fields. tab32 multi-location setups that use one patient record across locations preserve location as a custom field on the Contact for routing clarity.

tab32 insurance carrier name, group number, and subscriber ID have no native Freshsales equivalent. We preserve these as text custom fields on the Contact record for reference. Full claim history and EOB data do not migrate — dental billing is a PMS function outside Freshsales' scope.

CDT codes (Current Dental Terminology) used in tab32 treatment plans and appointments have no Freshsales taxonomy. We capture CDT codes as a text custom field on the Activity record so procedure history is searchable. The CDT description maps alongside the code for human readability in Freshsales.

tab32 treatment plans store proposed procedures, case value, and clinical notes linked to a patient. Freshsales has no treatment plan object. We migrate treatment plan text as a long-text custom field on the Contact record. Complex multi-phase treatment plans may be exported as a PDF reference and linked as a note attachment.

tab32 recall scheduling (e.g., 6-month hygiene recall, annual perio maintenance) uses an automated reminder engine native to the dental PMS. Freshsales has no recall model. We preserve the recall frequency and next recall date as custom date fields on the Contact so the hygiene cadence is not lost — but automated reminders must be rebuilt as Freshsales workflows or handled in a dental PMS.

tab32 custom properties on patient, appointment, or provider records that have a Freshsales type equivalent (text, number, date, picklist) create Freshsales custom fields on the matching object. tab32 custom properties with no type match (e.g., clinical measurements) migrate as text custom fields or unstructured notes.

tab32 services rendered ( CDT codes as line items, fee schedules) map to Freshsales Products. Product name and unit price transfer directly. Products are then linked to Deals via deal line items. Note that CDT codes used as products require the CDT custom field mapping described above for full clinical traceability.

tab32 insurance claim records, claim status, and billing transactions have no Freshsales equivalent. We migrate claim summaries as Notes on the Contact record and export claim detail records as CSV attachments where claim-level data is needed for reference. Full billing history is outside Freshsales' scope.

For DSOs that track appointment production value as deals, we map tab32 appointment revenue to Freshsales Deal Amount, map appointment status to Deal Stage (Scheduled, In Progress, Completed, Cancelled), and use appointment date as the Close Date. This allows Freshsales pipeline reporting on appointment-based revenue by provider and location.

tab32 patients linked to a primary practice/location map to Freshsales Contact with an AccountId lookup to the corresponding practice Account. Patients associated with multiple tab32 locations map to one primary AccountId, with secondary locations stored as a custom multi-select field on the Contact for reference.