Migrate from Encharge to Twenty CRM

Encharge People records map directly to Twenty CRM Person records. Standard fields (email, firstName, lastName, phone, city, country) map to Twenty's Person object fields. Custom person fields in Encharge become custom fields on the Person object via Settings → Data Model before import. We use email as the dedupe key. Note that Twenty's Person object has limited standard fields out of the box; most Encharge custom fields require pre-creation in Twenty's schema during scoping.

Encharge Accounts (companies associated with People) map to Twenty CRM Company records. Company name, domain, industry, employeeCount, and address fields map to their Twenty equivalents. Company custom fields migrate as custom Company properties after pre-creation in Twenty's Data Model. We link Persons to their parent Company via the Person's companyId field during import.

Encharge Tags are flat string labels applied to People. Twenty CRM does not have a native tag system; we create a custom multi-select picklist field (e.g., personTags) on the Person object during schema setup and populate it with the Encharge tag assignments. If Encharge uses more than 150 unique tags, we split into multiple multi-select fields or use a text field with comma-separated values.

Encharge Segments are dynamic filter-based groups of People. Twenty CRM does not have a native segment engine; we export the segment definition (filter rules, operators, and values) and recreate it in Twenty as saved views with filter criteria on Person fields. For segments based on behavioral events not stored as Person fields, we create custom fields on Person and populate them during migration, then document the segment logic as a Twenty saved view specification.

Encharge Activities record behavioral events (email opens, page views, custom events, payment triggers) with timestamps. Twenty CRM does not have a native behavioral event log; we map Encharge Activities to a combination of custom fields on Person (lastEventName, lastEventDate, eventCount) and Event records for significant milestone events. For high-activity accounts, we may recommend a separate events table or a linked custom object to preserve the full timeline without cluttering the Person record.

Encharge Custom Objects (Deals, Orders, Invoices, or any domain-specific entity) map to Twenty CRM custom objects. We pre-create the destination schema via Settings → Data Model before migration, including all custom fields and lookup relationships. Custom object naming follows Twenty conventions. If Encharge Custom Objects reference People or Accounts, we resolve the Person/Company lookup IDs during migration to maintain referential integrity.

Encharge Email Templates (HTML with subject lines and sender metadata) export as HTML files with inline styles preserved. Twenty CRM does not have a native email template library; we deliver templates as a structured folder of HTML files with metadata (subject, from-name, from-email) documented in a CSV. The customer's team updates these in their chosen email sending tool post-migration.

Encharge Campaigns group emails and automation steps. Twenty CRM has no native campaign object; we map campaign names and status to a custom Campaign object that we create in Twenty's Data Model, or to the Opportunity object if campaigns represent sales cycles. Campaign-flow associations do not export and must be documented separately for rebuild.

Encharge Users (team members assigned as Flow owners and sending identities) map to Twenty CRM Users by email match. Twenty Users have roles and workspace permissions that Encharge does not model; we document the Encharge user roles and recommend Twenty workspace permission assignments during scoping. Users without a matching Twenty account go to a reconciliation queue.

Encharge Places store structured location data associated with People or Accounts. Twenty CRM Person and Company objects have address fields (streetAddress, city, state, country, postalCode). We map Place data to these fields, preserving structured location information where the destination schema supports it.