Migrate from folk to Twenty CRM

folk Contacts of subtype person migrate to Twenty Person records. We map standard properties (name, email, phone, social handles) directly to Twenty's Person fields. The original contact subtype is preserved in a custom field original_contact_subtype__c for audit. folk contact-level custom fields migrate to Twenty Person custom fields if the same field name exists across source Groups or is explicitly mapped in the per-Group field enumeration during discovery.

folk Contacts of subtype company migrate to Twenty Company records. Company name, domain, industry, size, and address properties map directly. The original contact ID is preserved as original_folk_id__c for relationship reconstruction. folk's company-type contact custom fields migrate to Twenty Company custom fields during the field enumeration phase.

folk Groups are organizational containers without a direct Twenty CRM equivalent. During scoping, the customer chooses one of two strategies: (1) Tags strategy — each Group becomes a Twenty Tag applied to Person records, preserving group membership as a label. (2) Pipeline strategy — Groups with pipeline views become Twenty Pipeline stages under a single Opportunity object, with Group membership preserved as a custom picklist field on Person. The customer selects the strategy before migration begins; mixed strategies are not supported.

folk custom fields are defined per-Group, not globally. During discovery we enumerate every Group's field schema, identify fields that exist across multiple Groups with the same name and type (which map to a single Twenty field), and flag fields that exist in only one Group (which require a decision: add to global Twenty schema, store as a JSON blob in a custom field, or drop). We resolve this decision with the customer before field creation in Twenty.

folk Notes attached to Contacts migrate to Twenty Comment records linked to the corresponding Person or Company. Note text, author attribution, and creation timestamp migrate directly. Note attachments (file URLs in the CSV) migrate as attachment links if Twenty's attachment model supports URL-based linking; file re-upload is attempted where the destination configuration allows.

folk Reminders migrate to Twenty Task records. Reminder text becomes Task title, due date becomes the due date, and assignee resolves via email match to a Twenty User. Unassigned reminders (no owner in folk) are imported with no assignee and flagged for manual assignment post-migration.

folk tags migrate as string values stored in Twenty's Tag model. Multiple tags per Contact become multiple Tag records linked to the Person via the personTag junction object. We deduplicate tag names during import to avoid duplicate Tag records in Twenty.

folk pipeline views exist per-Group. We map each pipeline view to a Twenty Pipeline object, with each folk pipeline stage mapped to a Twenty Pipeline Stage. The mapping is 1:1 for stage names. Closed-won and closed-lost stage behavior requires manual configuration in Twenty after import because Twenty's pipeline stage probability settings are UI-configured, not data-level.

folk activity history (emails sent, meetings logged, calls) appears partially in the CSV export. We extract what is present and map to Twenty's TimelineEvent or Task object. Activity timeline completeness is limited by what folk exposes in CSV; we flag gaps in the migration report and note that email content from sent emails may not be fully captured.

folk attachments stored as URLs in the CSV export are attempted for re-upload to Twenty where the destination supports it. File size limits, hosting restrictions, and URL validity are checked during import. Attachments without valid URLs (stored as folk internal references) cannot be migrated. We flag any attachment that fails migration in the reconciliation report.