Migrate from Nookal to Twenty CRM

Nookal Client records map directly to Twenty People. Client name, email, phone, address, and date of birth transfer as standard fields. Each client must have a primary practitioner assigned in Nookal, which we map to the Twenty Workspace Member (user) who owns the Person record after email-matching resolution.

Nookal stores practitioner-client relationships with role labels (e.g., 'primary physiotherapist'). We map these to a custom pick-list field (Practitioner_Role__c) on the Person record and set the Twenty workspace member as the record owner via email lookup. If a practitioner has no Twenty account, records attach to a designated fallback owner and the unresolved practitioner name is preserved in a custom text field.

Nookal appointments map to Twenty Tasks with the original start/end datetime preserved. The Task title carries the appointment type (e.g., 'Initial Consultation', 'Follow-up Treatment'). Task status maps from Nookal's appointment status: 'Completed' → Twenty Task 'completed'; 'Cancelled' → 'cancelled'; 'Scheduled' → 'open'. The assigned practitioner maps to the Task assignee via email resolution against Twenty workspace members.

Nookal service types (e.g., 'Physiotherapy - Standard', 'Podiatry - Initial') have no direct Twenty equivalent. We create a custom select field (Service_Type__c) on the Task object and populate it with the Nookal service-type values. Your admin maps which service types are available in Twenty's Settings → Data Model before the full migration runs.

Nookal invoices carry total amount, status (paid/unpaid/overdue), and line items. Since Twenty has no native invoicing object, invoice data migrates as custom fields on the Person record: Invoice_Total__c (Number), Invoice_Status__c (Select: Paid/Unpaid/Overdue), and Invoice_Date__c (Date). Each invoice record in Nookal becomes a separate set of these fields, with invoice ID preserved in Invoice_ID__c for reconciliation.

Nookal Medicare/DVA claiming records contain provider numbers, service dates, item codes, and claim status. These map to custom fields on Person: Claim_Status__c (Select), Claim_Item_Code__c (Text), Claim_Provider_Number__c (Text), and Claim_Date__c (Date). The claiming workflow itself (provider-number mapping, AIR integration) cannot migrate and is exported as a reference document for rebuild in Twenty's workflow builder.

Nookal clinical notes and treatment records migrate as Twenty Notes attached to the Person record. The Note body carries the full clinical text. Original note datetime and practitioner author transfer as Note metadata fields. Note that clinical note content from Nookal may be PHI-sensitive—your team controls access permissions in Twenty via workspace roles.

Nookal multi-location practices store location data per appointment and client. We create a custom select field (Practice_Location__c) on the Person record populated from Nookal's location list. If your Nookal setup stores practice details as separate records, those map to Twenty Companies with location address data.

Nookal's Xero and QuickBooks integration links invoices to accounting records using external IDs. These IDs have no Twenty equivalent since Twenty lacks native accounting sync. We preserve the external accounting reference as a custom text field (Accounting_Reference__c) for manual reconciliation after migration.

Nookal practices often add custom fields for health-specific data (e.g., 'NDIS Plan Number', 'Allergies', 'Emergency Contact'). Each custom field requires a matching Twenty custom field created in Settings → Data Model before import. We inventory all Nookal custom fields during the audit phase and deliver a field-creation checklist so your Twenty workspace is schema-ready before data lands.