Migrate from Rule to Twenty CRM

Rule contact profiles (name, email, phone, behavioral attributes, channel preferences) map to Twenty Person records. We preserve all Rule custom contact properties as Twenty custom fields. Note that Twenty's standard Person object intentionally lacks many standard fields that Rule provides natively—GitHub issue #13953 documents that new users must spend 30-60 minutes creating basic fields before productive use. We pre-create all required custom fields during schema setup so Person records land with complete data on first import. The Rule lifecyclestage property migrates as a custom picklist field on Person.

Rule Company records map directly to Twenty Company. Company name and domain map to displayName and websiteUrl respectively. We use domain as the dedupe key during import to prevent duplicate company records. If Rule stores account-level custom fields, we create matching custom fields on the Twenty Company object before migration.

Rule Deal records map to Twenty Opportunity. We resolve the Company (Account) lookup before Opportunity insert so that every opportunity is attached to its parent company. Deal stage names map to Twenty pipeline stage values, and the Rule deal owner maps to a Twenty workspace member.

Rule segments are dynamic filter-based lists. We export segment definitions as written filter logic rather than snapshots, noting each segment's filter conditions, combinators, and value criteria. Twenty does not have native dynamic segments; we document each Rule segment as a filter configuration that an admin can recreate in Twenty's Table view filters or Kanban grouping. For critical segments, we create static saved views in Twenty during migration.

Rule Automation Workflows contain trigger conditions, time delays, and channel actions. We do not migrate workflows as code. We deliver a written inventory of every Rule workflow with its trigger type (event-based, date-based, tag-based), conditions, action sequence, and channel target. Twenty's workflow builder supports record-triggered and scheduled automations; the inventory document maps each Rule workflow to a recommended Twenty equivalent. The customer's admin rebuilds workflows post-migration.

Contact and company tags in Rule map directly to Twenty's tag field. Tags are preserved per record at migration time. Both platforms support multiple tags per record with no hard limit.

Rule email engagement events (opens, clicks, bounces, unsubscribes) export as a structured dataset. We import these as Twenty Activity records with the activity type annotated as email_open, email_click, email_bounce, or email_unsubscribe in a custom field. The original Rule timestamp becomes the activity date for chronological accuracy. Whether Twenty surfaces this history in its activity timeline UI depends on the Twenty version and view configuration.

Channel-specific engagement events from Rule (SMS sends, RCS messages, social interactions) export separately from email events. We consolidate these into Twenty Activity records annotated with channel type (sms_send, sms_reply, rcs_message, social_engagement) in a custom field. This mirrors how Rule itself siloes channel data; consolidation at migration time gives Twenty a more unified view than Rule provides natively.

Rule custom fields on contacts and companies (dropdown, date, numeric, text, multi-select types) map to Twenty custom fields of equivalent type. Multi-select fields require explicit mapping to Twenty's multi-select implementation. We create the destination custom fields in Twenty's metadata API before any data import so that schema is ready before records land.

Email and SMS templates in Rule (body text, subject lines, dynamic variables) export as content files. We deliver a template inventory with full body copy and subject line text. Dynamic variable syntax differs between platforms; Twenty's template system does not have a native Rule equivalent, so templates are documented for manual rebuild in Twenty or through the customer's email sending tool.

Rule user accounts (name, email, role) map to Twenty workspace members by email match. We extract all Rule users referenced on records, match against Twenty workspace members, and flag any unresolvable users for admin provisioning before record import. Unmatched owners receive a placeholder assignment with a flag for reassignment post-migration.

Rule suppression lists (unsubscribed, bounced, blocked contacts) export as a distinct dataset. Twenty does not have a native suppression list object; we apply a custom status field (suppression_status) to each suppressed contact record with values unsubscribed, bounced, or blocked. The customer's admin applies this status in Twenty's contact list view post-migration.