Migrate from Salesflare to Twenty CRM

Salesflare Account records map directly to Twenty Company. The company domain, industry, location, and custom properties migrate to matching Twenty fields or pre-created custom fields. Company is created before any People import so that the People-Company relationship is satisfied at insert time. Salesflare's account-level tags migrate to Company Tags in Twenty via a many-to-many join table preserved during migration.

Salesflare Contact records map to Twenty People with the Account-Contact junction preserved as a Company link. Name, email, phone, title, social links, and enrichment data from email signature scraping migrate to matching Twenty People fields. Primary vs. secondary contact roles are stored in a custom field on People. Manual address data migrates as a text block if Twenty's address compound field is not available.

Salesflare Opportunity records map directly to Twenty Opportunity. Deal value, stage, expected close date, and pipeline assignment migrate to matching Twenty Opportunity fields. Pipeline stage names from Salesflare map to Twenty Opportunity stage values; the customer defines the stage mapping during scoping because Twenty stage values are user-configured.

Salesflare pipeline definitions export as metadata alongside Opportunity records. Each Salesflare pipeline becomes a Twenty opportunity status group or a named view filter. We document the full stage-to-status mapping so the customer configures Twenty's opportunity pipeline stages in Settings before migration begins.

Salesflare logged calls map to Twenty Task records with a custom call-type indicator. Call outcome, duration, and any notes migrate to Task custom fields. The Task is linked to the parent Company and People records via Twenty's relationship fields. Activity timestamps are preserved for timeline ordering.

Salesflare email engagements migrate to Twenty as Note records or Task records with an email-type indicator depending on whether the customer prioritizes timeline display or searchable content. Email body, subject, and direction (sent/received) are preserved in Twenty custom fields. We document the preferred email mapping strategy during scoping.

Salesflare meeting engagements migrate to Twenty Note records with meeting metadata (date, attendees, location) in custom fields. Attendee names link to People records where email addresses match. The customer's meeting frequency determines whether meetings are stored as Note or Task for optimal calendar integration.

Salesflare standalone notes migrate to Twenty Note records linked to the appropriate Company or People record. Note body preserves rich text formatting where supported. Notes without a parent record are flagged in the reconciliation report for the customer to resolve.

Salesflare flat tags on Accounts, Contacts, and Opportunities migrate to Twenty Tags applied to the corresponding record types. Tag names and associations are preserved as a many-to-many join table. No hierarchy or inheritance exists in either system, so each tag assignment migrates as an independent record.

Salesflare Users (team members) map to Twenty Members. We resolve by email match against the Twenty workspace members list. Members must be invited and accepted in Twenty before migration begins so that Opportunity owner references resolve correctly. Any unmatched owners are held in a reconciliation queue for manual provisioning.

Salesflare custom properties on Accounts, Contacts, and Opportunities migrate to Twenty custom fields created in Settings Data Model before import. We export the full property map per object, create the corresponding custom fields in Twenty with matching types (text, number, date, select), and then map property values during the data load phase.

Salesflare custom objects (Pro and Enterprise) map to Twenty custom objects of equivalent name. The destination schema, including all custom fields and lookup relationships to standard objects, is pre-created in Twenty Settings Data Model before migration. Custom object records migrate after all standard objects to satisfy foreign key constraints.