Migrate from Iterable to Twenty CRM

Iterable User Profiles map directly to Twenty People records. The dataId, email, userId, and all custom profile fields migrate as named fields on the People object. We preserve system fields like createdAt and updatedAt as readonly date fields. Subscription status per channel (email, SMS, push) migrates as boolean fields (emailSubscribed, smsSubscribed, pushSubscribed) so opt-in state is auditable in Twenty without a separate subscription management module.

Iterable does not have a native Company/Account object; companies are referenced via custom fields on User Profiles. During scoping, we audit which custom fields hold company name, domain, or account identifiers. If these fields exist, we extract unique values, deduplicate, and create Company records in Twenty, then resolve the lookup relationship back to People via a custom field companyId that we populate during People import.

Iterable Custom Events (behavioral data with name, userId, and arbitrary metadata payload) migrate as Twenty Custom Objects. We create a custom object schema in Twenty matching the event's metadata field structure, then import historical event records with a lookup to the associated People record. Event timestamps migrate as the Custom Object's createdAt. The event name becomes a field on the Custom Object for filtering in Twenty's views.

Iterable Lists are audience segments used for campaign targeting. Twenty has no native list object, so we offer two migration strategies during scoping: (1) comma-separated tags migrated to a multi-select field on People, or (2) list membership stored as a JSON field with list names as values. The customer chooses based on how they use Lists in Iterable. Both approaches allow filtering in Twenty's views and workspaces.

Iterable Campaigns (sendable units with name, channel, template, and schedule) are exported as structured metadata with channel, status, and schedule preserved. Campaign content does not migrate because Twenty has no native email or SMS sending engine. We deliver a Campaign Inventory document listing every Iterable Campaign with its send history, channel type, and associated template, which the customer's admin uses to rebuild campaign logic in Twenty Workflows or a separate sending tool.

Iterable Journeys are multi-step, multi-channel automation paths with trigger conditions, branching logic, and message actions. Twenty Workflows are code-based action sequences that operate on Twenty records and external API calls. These are fundamentally different automation models with no structural equivalence. We do not migrate Journeys as code. We deliver a written Journey Inventory listing every active Journey with its trigger type, conditions, branch paths, and associated message steps so the customer's admin can rebuild in Twenty Workflows or an external sending tool.

Iterable Templates define message content (HTML email, plain text, dynamic Handlebars personalization) for Campaigns and Journey steps. Twenty CRM has no native template engine. We export template metadata (name, channel, content type, personalization variables) to a Template Inventory document that the customer's admin uses to reproduce content in their chosen sending tool (e.g., Postmark, Resend, Klaviyo) with dynamic fields mapped to Twenty People record fields.

Iterable Catalog stores product data used for dynamic content insertion in messages (product name, SKU, price, image URL, attributes). We export Catalog schemas and item records as CSV and import them into a Twenty Custom Object (e.g., Product Catalog) with fields matching the source schema. The customer must rebuild any Catalog-driven personalization logic (e.g., product recommendations in emails) using their chosen sending tool's dynamic content system post-migration.

Iterable Purchase events (orderId, total, items, associated user) migrate as a Twenty Custom Object (e.g., Purchase) with a lookup to the People record. Order ID, total amount, currency, and item count migrate as typed fields. The line items array is stored as a JSON field if the customer needs granular item-level data, or flattened into summary fields if simpler reporting is sufficient.

Iterable tracks channel-level opt-in/opt-out state per user (email, SMS, push, in-app). We migrate each channel's subscription status as a boolean field on the People record (emailSubscribed, smsSubscribed, pushSubscribed). Subscription event history (opt-in timestamp, opt-out timestamp, source) is preserved as activity notes on the People timeline if available in the Iterable export. This satisfies GDPR accountability requirements for consent records.