Migrate from Iterable to Freshsales

Iterable User Profiles map to Freshsales Contacts using email as the dedupe key. System fields firstName, lastName, email, phoneNumber, and userId migrate to Freshsales standard contact fields. All active custom profile fields migrate to Freshsales custom contact fields, preserving data type (string, number, boolean, date). We flag Iterables deprecated fields during scoping and exclude them from the import. If the custom field count exceeds Freshsales practical limits, we consolidate redundant fields during the mapping phase.

Iterable Custom Events track behavioral data beyond profile updates, including event name, timestamp, and arbitrary metadata. Freshsales has no native behavioral event object, so we store event data in Contact-level custom fields. For migrations where event history is required, we create a custom text field event_history__c storing a JSON array of event names and timestamps, and a separate custom field last_event__c holding the most recent event name and date. We scope event history retention with the customer before migration to avoid field size issues.

Iterables per-channel subscription state (email, SMS, push, in-app) maps to Freshsales Contact compliance fields. The standard Freshsales HasOptedOutOfEmail field receives the email subscription status. SMS, push, and in-app opt-out states map to custom contact fields sms_opt_out__c, push_opt_out__c, and in_app_opt_out__c as boolean values. We preserve the full subscription event history in a custom text field subscription_history__c as a JSON log for compliance audit.

Iterable Lists are collections of User Profiles used for audience segmentation. We migrate List names and membership to Freshsales by creating a custom multi-select picklist field list_membership__c on Contact, with each Iterable List name as a picklist value. Contact records are set to all List names they belonged to in Iterable. If the number of Lists exceeds the multi-select picklist practical limit, we create a tag-based alternative using Freshsales native contact tags.

Iterable Campaigns are sendable units with names, channels, templates, and schedules. Freshsales does not have a native Campaign object in the base CRM (Campaign belongs to Sales Cloud which may not be active on the customers plan). We store campaign metadata as reference records in a custom Contact field campaign_history__c holding campaign names, send dates, and channel type as a JSON log. We flag which campaigns had active sends during the migration window for the customer to reconcile against Freshsales reports.

Iterable Purchase events record transaction data (orderId, total, items, associated user). We map Purchase records to Freshsales Deals by grouping all purchases by User Profile email and creating one Deal per customer with aggregated purchase data (total revenue, order count, first purchase date, last purchase date) stored in custom Deal fields purchase_total__c, order_count__c, first_purchase_date__c, and last_purchase_date__c. Individual order line items are stored as a JSON array in a custom field order_items__c on the Deal.

Iterable Catalog Items define product data used for dynamic content insertion. Freshsales has a standard Product object for sales pipeline items. We migrate Catalog schemas and item records to Freshsales Products with Catalog item attributes mapped to custom Product fields. Note that Catalog relationships to Journey steps in Iterable must be re-established in Freshsales manually because the dynamic content injection logic has no Freshsales equivalent.

Iterable Journeys define multi-step, multi-channel automation paths with trigger conditions, branching logic, and message actions. Freshsales has a basic Workflow automation engine (Pro tier and above) that handles record-triggered updates and task creation but does not replicate Iterables Journey builder scope. We do not migrate Journeys as automation code. We deliver a written inventory of every active Journey including trigger conditions, step sequence, channel actions, and conditional branches for the customers admin to rebuild as Freshsales Workflows or document as manual processes. Journey re-trigger behavior is flagged because Freshsales Workflows do not support the same re-entry rules.

Iterable Templates define message content using HTML, plain text, and Handlebars personalization syntax. Freshsales has an Email Templates feature but it does not accept raw HTML imports or Handlebars expressions. We export template content and metadata as a written reference document and deliver it to the customers admin for recreation. We do not convert HTML templates or migrate Handlebars logic automatically because content rendering depends on Freshsales template syntax which differs from Iterables.

Iterable Owners associated with User Profiles map to Freshsales Users by email match. We extract all distinct Owner references from Iterable profiles and cross-reference against Freshsales Users. Any Owner without a matching Freshsales User goes to a reconciliation queue for the customers admin to provision before record import. Owner records are required to be resolved before Contact migration begins so that the OwnerId reference is satisfied at insert time.

Iterable Data Sync exports warehouse data for BI use. Freshsales does not have a native warehouse export feature on Growth and Pro tiers. If the customer uses Data Sync records for reporting, we migrate the most recent Data Sync snapshot fields as custom Contact fields or store the data in a custom object. We note that ongoing Data Sync requires an alternative export method post-migration such as Freshsales native reporting exports or a third-party BI connector.